カテゴリー: Pet
甲斐犬のキクと散歩
甲斐犬のキクと元宇品の山
ひろしまみなとマルシェに 内部監査支援システム開発
朝は元宇品に散歩に行き、帰りにひろしまみなとマルシェに寄ってみる・・・炎天下の下、出店している人たちには脱帽ものです・・やはりお客は少なく営業的には苦しい・・・よしろう農園でしばらく雑談して帰宅、シャワーを浴びたらもう昼食
帰って月下美人を見ると昨晩に咲いていた・・残念見ることができなかった

内部監査支援システム開発
内部監査の指摘では、監査員の力量に左右されて的確な条項に基づく指摘が出来ていないのが実情である・・・今回、力量の不足をAIによって支援するシステムのモデルを構築する・・以下の課題は2点がメインだが、TAMの監査指摘4年分をデータ化し構造化することによって支援の形態が現実的に見えてきた
- AIに情報を渡すが、その情報が漏洩リスクとならないために、固有名詞などを送らせない
- 具体的な支援方法について、イメージが具体的にならない
内部監査システム構築のためのステップ
- STEP 1-1: 事実メモを箇条書きで入力(固有名チェックあり。通らないと進めない)
- STEP 1-2: AIが事実の不足を質問(最大3問×2ラウンド。スキップ可)
- STEP 1-3: 対話結果から事実文を自動文書化 → 監査員が修正・確定
- STEP 2: 条項候補Top-3+境界注記 → 選択または手入力
- STEP 3: ランク選択 → 指摘文案生成 → 修正
- STEP 4: 確定 → 事例DBに蓄積(次回のAI参照例に自動反映)
これまでに構築したもの
- [TAMの審査記録xlsx 4年分をデータ化してサンプルとする] : audit_case_extract(抽出+三段匿名化: パターン/辞書/ローカルLLM検査)
- [匿名化済み事例DB cases.csv 388件] :clause_bench(条項マッチング実力測定)
- [実測: ゼロショット85.5%/適合性系93.8% → RAGで88.1%・混同半減] :検討結果書(二層アーキテクチャ: 規格層=共通/流儀層=組織別)
- [audit_assist_proto(動くプロトタイプ)] :事実引き出し対話 → 匿名化ゲート → 条項候補 → 人間確定 → 事例蓄積(自己学習)
主要な実測値(仕様書の根拠数字)
- 条項マッチング(Top-3実務粒度): ゼロショット全体85.5% / 適合性系93.8%
- 粒度規約+TAM事例RAG(v2b): 全体88.1%、最大混同ペア(8.1↔6.1.2)半減
- ランク別定型句の対応(388件分析): 改善の機会=「推奨します」、観察事項= 「検討の余地があります」が相互汚染ゼロの完全分離 → 文章生成テンプレートに採用
- 適合性系(観察事項・懸念領域・改善指摘)と意見系(改善の機会・充実点)の 2群構造を確認 → ランクはAIが当てず、2分類推定+監査員選択の設計に
実地試用の状況と次回のTODO
済み: 2022年審査データで10件試用・・「力量ある監査員には良い指標」との評価・・記録済みデータ: confirmed_cases.csv・metrics.jsonl に実データ10件保持
次回確認すること:
- v1.1修正の適用確認(重要): v1.2完了報告にv1.1(過剰検知修正・許可ボタン・ ランク2分類化)の適用言及がない。「建築部」「工務課長」「2件の作業所」が ブロックされないか確認し、未適用ならv1.1指示書を先に適用させる
- 採用率18.2%の原因調査: 体感(「非常によくできている」、明確な条項誤りは1件)と 記録上の採用率18.2%が大きく乖離している。候補カードをクリックせず手入力で 条項を入れる操作習慣だと、候補が正しくても「手入力=不採用」と記録される。 metrics.jsonlの確定条項の生値と候補を突合し、指標定義の問題か候補品質の問題かを 切り分ける(次回セッションでmetrics.jsonlをアップロードすれば分析可能)
- 1.2の意地悪テスト: 最低品質のメモ(「・教育記録を確認 ・不十分」)への AIの質問が、TAMが新人に返す問いと一致するか 試用を10〜20件継続し、指標の推移を観察
暑い朝の散歩 ローカルLLM(Ollama)の構築

ローカルLLM(AI)の構築
ローカルLLMとして、Ollamaを選択、ローカルでOpenAI互換APIを提供、Laravelから通常のAPI呼び出しと同じ形式でローカルLLMを叩ける
インストールするWindowsPCは、・マザー ASUS ROG STRIX B550-A GAMING、CPU Ryzen9 3950X(16C32T 3.5-4.7GHz)、メモリ DDR4 PC4-28800 3600MHz 2✕32GB=64GB、グラフィックボード GeForce RTX™ 4070 Ti、M.2SSD PCle4.0 NVMe M.2 Kingston KC3000 1021GB、 PCIe Gen 4.0 x4 70000MB/Sで、GPUが少し不足気味だが、Ollama Qwen2.5 14B (Q4量子化 約9GB)が動きそうなのでインストールして試行する
Ollama本体のインストール
https://ollama.com/download/windows からOllamaSetuo.exeをダウンロード 実行してインストール、インストール後、Ollamaは常駐サービスとして起動します(タスクトレイにラマのアイコン)
NVIDIAドライバの確認
nvidia-smiを実行して、ドライババージョンとRTX 4070 Ti、VRAM 12288MiBが表示されればOK
モデルの取得と実行
ollama pull qwen2.5:14bをダウンロード完了したら、ollama run qwen2.5:14bで起動して、プロンプトから質問できる
GPU配分の確認
ollama psと入力して、OROCESSORが100%GPUとなっているので、VRAMに全部納まっている
API経由での動作確認(サーバ連携の予行)
Ollamaは自動的にhttp://localhost:11434でAPIを開いているので、Laravelから叩く検証ができる
Jeepの車検
今朝も暑い、キクを連れて元宇品を散歩、キクはタヌキを見つける・・・走りすぎてバテてました・・・午前中に、J58の車検に、無事に終わって、今回はブレーキオイルを入れ替えたので¥5万程、昼からNGIさんが訪ねて来て久しぶりに雑談


キクと散歩 工事一覧の変更
元宇品を散歩

その他の改善
- キャンバス表示範囲の拡張:工期ぴったりの表示から「工期の前後1ヶ月」に拡張。工期前後への工程配置が可能になり、読込時は工期開始位置へ自動スクロール。印刷は従来どおり指定範囲のみ
- 印刷範囲外工程の除外:バーチャートの印刷で範囲外の工程・接続線が出力される問題を修正。あわせてアノテーション(テキスト・フリー線)が印刷範囲変更時にずれる問題も修正(日付アンカー方式を導入)
- フリー線の太さ・矢印修正:太さ変更が即反映されない問題と、1pxで矢印が見えなくなる問題を修正(矢印を固定サイズに変更)
- ダブルクリック編集の修正:委譲化により発生した問題。DOM再構築のタイミング制御(requestAnimationFrame遅延・3px閾値)で解消
結果
| テスト | TenantIsolationTest 33件パス維持(全修正通じて) |
| 主な成果 | アノテーション機能の2画面統一・印刷品質の大幅改善 |
| 特記 | 印刷残像の根本原因はデバッグコードの消し忘れ1行だった |
工程表(バーチャート・ネットワーク)の品質改善
アノテーション機能の全面整備(メイン作業)
背景:2画面でアノテーション(テキストボックス・フリー線)の実装がバラバラで、barchartに欠けている機能が多かった・・設計書を作成してから4段階で実装した
| 1 | networkのイベント処理を委譲方式に統一(個別リスナー8箇所を撤去) |
| 2 | barchartにnetwork同等の機能を追加(ドラッグ移動・端点編集・描画プレビュー等) |
| 3 | UXルール統一(配置後即モーダル表示・ワンショット化) |
| 4 | 共通コード(schedules-common.js)として抽出・約230行の重複削減 |
あわせてモーダルのUI表記も両画面で統一(ボタンラベル・フォント選択肢・フリー線太さをselect化等)・・・P4完了後に発覚した退行(barchartのテキストボックス):長文・大フォントで文字が枠からはみ出し、クリック・ダブルクリックが効かなくなる問題。原因はforeignObjectの固定サイズ・・・networkにあった「文字量に合わせた自動拡大」が移植漏れだったため、共通モジュールに追加して解消
印刷機能の連続修正
| 問題 | 原因 |
|---|---|
| 印刷後に背面に残像が残る プレビュー表示中も残像が見える | try/finally未実装で復元処理が漏れる可能性 描画凍結中にpaintが完了しない |
| そもそも消えない | デバッグ用のコメントアウトが残ったまま |
| 月境界線が太すぎ・テキストの上に乗る | 旧レイアウト時代の「貫通線」が残存していた |
| 月境界線が「時々」途切れる | UTC変換による日付の1日ずれ(タイムゾーンバグ) |
楽観ロック実装
楽観ロックとは
複数ユーザーが同じデータを同時に編集した際、後から保存した人の内容が前の人の変更を上書きしてしまう問題を防ぐ仕組み
共通基盤の構築
4ファイルを新規作成して土台を整備
| ファイル | 役割 |
|---|---|
| ChecksOptimisticLock.php(トレイト) | サーバー側の照合・トランザクション・409返却 |
| optimistic-lock.js | フロント共通ミックスイン(トークン保持・競合処理) |
| conflict-modal.blade.php | 競合通知モーダル(退避DL・最新読込ボタン) |
| OptimisticLockTest.php | 検証テスト |
葡萄が実っている 工程表をJS外部化
梅雨明け宣言が出た広島だけど、あまり天気は良くない・・少しじっとしてあまり風も吹かない・・・今日は元宇品の森から海岸降りる道は、2カ所ともバリケードが設置してあり・・・海岸の遊歩道が山崩れでした・・・海岸線は誰1人いません・・いつもは釣りに人や散歩の人が多いんですが・・まぁのんびりとね海岸でキクを散歩させながら歩きます


工程表JS外部化
バーチャートと工程表のBladeファイルに数千行のJSがインライン記述されていた
| barchart.blade.php 2,439行 → 682行 |
| network.blade.php 3,083行 → 732行 |
| インラインJSを外部ファイルへ移設 約4,300行→1,414行 |
設計のポイント:
Blade側はJSON設定タグのみ残し、外部JSが読み込む方式を採用。これにより将来CSPのunsafe-inlineを除去できる構造になった
印刷用共通JS(518行)も共通モジュール化し、print-common.jsとして整理
着手前に工程表全体のモーダル構成を調査し、2画面間の実装差異(件数カウントのズレ・GW休日のデッドデータ等)も記録した(今回は修正対象外)
施工計画書「旧版」廃止(Phase 1・2)
長期間放置されていた旧版施工計画書のコードを2段階で削除
Phase 1:孤立コンポーネントとAPIルート4本を削除
Phase 2:本体を削除
| 削除対象 | 規模 |
|---|---|
| ルート | 13本削除 |
| コントローラメソッド | 8関数削除(960行 → 290行) |
| ビュー | フォルダごと削除 |
注意点:Phase 2着手直後にgetTemplateContentを誤削除していたことが判明(管理画面が使用中)→ 即座に復活させて修正・・本番データ(construction_plan_items 208件)はテーブルごと残置、コードのみ削除という方針で対応
PDF様式取込:sonnet vs haiku 品質比較
Step 8移行でPDF取込がhaiku→sonnetに変わったため、実際に品質を比較検証した
haikuの誤読は単純な省略ではなく意味の破壊で、施工計画書として実用不可レベル:sonnet維持を確定。PDF取込はセットアップ時の低頻度操作のため、コスト増の影響は限定的
成果まとめ
| 項目 | 内容 |
|---|---|
| コード削減 | インラインJS約4,300行を外部化・旧版コード約670行削除 |
| 品質検証 | PDF取込のsonnet採用を実データで根拠付け |
| テスト | TenantIsolationTest 33件パス維持 |
J58フロントドライブシャフトブーツの交換
雨のみなと公園
キクと元宇品

2.onclick / onchange インラインハンドラを addEventListener に移行する
サーバー側のバリデーション・サニタイズと、ブラウザ側のCSPの両方が必要
- グループA:サイドバー(id 付き → そのまま addEventListener)
- グループB:サイドバー(id なし → id を付与してから addEventListener)
- グループC:ページタブバー(id なし → id 付与)
- グループD:ナビバー(Blade 条件分岐内)
- フローティングRTB(書式ツールバー)のインラインハンドラ移行
施工計画のエディット画面(edit_section_blade.php)が、ほぼ実装が完了したので、再びコードの検証を行う・・・やはり、まだ課題が多く残っていたので、順にコードの手直しをする
1.生HTML出力({!! !!})を使用している
{!! !!} はエスケープなしの生出力のため、$headerHtml / $footerHtml がDB経由で、悪意あるスクリプトを含む場合、XSS攻撃が成立する。
サーバーサイドでのサニタイズ(無害化)状況を確認し、不十分であれば修正する・・・XSS(クロスサイトスクリプティング)、SQLインジェクション・・以下はサニタイズの手法
| 手法 | 内容 |
|---|---|
| エスケープ | 特殊文字を無害な表現に変換(< → <) |
| 除去 | 危険な文字・タグを削除 |
| バリデーション | 想定外の値を拒否(数字のみ受け付けるなど) |
| プレースホルダ | SQLをコードと分離して処理 |
これらの手法は、Laravelでは多くは自動で処理してくれるが、施工計画のSVGダイアグラムエディタのような自前JS処理部分は別途確認が必要
1-1.データの流れを追跡する
- コントローラを特定する(ルート名 project_plans.sections.editから逆引きする)
- $headerHtml / $footerHtml の生成箇所を特定する
- DBカラムの確認
1-2.現状の判定(サニタイズ処理必要性の検証)
- ✅ 安全なケース(修正不要)
- ❌ 要修正なケース(対応する、入力時サニタイズ、HtmlPurifier の導入確認、サービスクラスまたはヘルパーの作成、コントローラの保存処理にサニタイズを追加、既存DBデータの一括サニタイズ(Artisan コマンド))
1-3.実施結果
Claude Codeでの実施結果ではOK、変更なし、コメントを追記
J58を修理工場に
今週は天気が悪くなるとのことだが、良い天気の月曜日、朝は久しぶりに元宇品の森を歩く・・・最近は、森のアップダウンの散歩は辛くなってきている、午前中は今週の仕事の段取りをして、昼からはキクを助手席に乗せてJ58を修理工場に移送
最近は旧車を修理してくれる修理工場が無い、昔の車の修理はわからないそうだ・・・いつもの修理工場に無理を言ってお願いする、パーツがあればとのことなので、パーツリストからパーツを頼むが、あっているか少し不安、パーツも中々高価で、失敗すると痛手が大きい、修理の期限は付けないが7月中には終わらせてもらいたい


墓参り 工事管理の見直し

1-2. edit_overview.blade.php 削除
| 変更 | 詳細 |
|---|---|
| edit_overview.blade.php | 削除 |
| routes/web.php | projects.overview.edit / projects.overview.update ルートを削除 |
| ProjectController | editOverview() / updateOverview() メソッドを削除 |
残留リンク確認: resources/views/projects/ 内に overview ルートへの参照なし(削除前にgrep確認済み)

2.show.blade.php — 工事編集ボタンの移動
変更前: <x-slot name=”nav_extra”> でヘッダータブとして表示
変更後*: 工事名・ステータスバーの右端にボタン配置
[ 工事名 (施工中) ] ··················· [ 部署: ○○ ] [ 担当: ○○ ] [ ✏️ 工事編集 ]

プロジェクト管理プロセスのセキュリティ及びファイルの健全性を検証
1.コードファイルの統合
1-1. create.blade.php + edit.blade.php → edit.blade.php(統合・create 削除)
統合方法:
- $project->exists(Eloquent 未保存インスタンスかどうか)で動作を切り替え
- 新規モード(exists = false): フォーム action → projects.store、HTTP method → POST、入力値なし
- 編集モード(exists = true): フォーム action → projects.update、HTTP method → PATCH、old() + 既存値
- ヘッダー文言・キャンセル遷移先・会社名ソース・nav_extra タブをモードで分岐
- ProjectController@create() を view(‘projects.edit’, [‘project’ => new Project()]) に変更
- 影響範囲: index.blade.php の route(‘projects.create’) はそのまま動作(resource ルートは維持)
| 変更前 | 変更後 |
|---|---|
| create.blade.php(新規登録専用) | 削除 |
| edit.blade.php(編集専用) | create+edit 統合版に書き換え |
元宇品散歩 建設アシスト安パト見直し

2-2.承認済みパトロールの編集ロック不完全
SafetyPatrolController.php saveDraft()メソッドshow.blade.phpのUIは$isLockedフラグで編集を無効化しているが、saveDraftエンドポイントにはis_finalizedチェックがなく、直接POSTで承認済みデータを上書き可能
修正
php
public function saveDraft(Request $request, Project $project, $id)
{
$this->authorizeProject($project);
$safetyPatrol = SafetyPatrol::findOrFail($id);
// 承認済みは変更不可 if ($safetyPatrol->is_finalized) { return response()->json([‘success’ => false, ‘message’ => ‘確認済みの記録は変更できません。’], 403); } //
2-3.CLAUDE.md との相違点
| 項目 | 問題 | 対象箇所 |
|---|---|---|
| session(‘success’)表示 | CLAUDE.mdでは `toast.blade.phpは error のみ表示とあるが、`show.blade.phpに独自のsuccess表示が存在 | show.blade.php` L23-27 |
| ` 未使用 | 一覧のボタン群が直接 <button class=”bg-indigo-600…”>等で実装されている | index.blade.php` L43-53 |
| ファイル先頭の説明コメント欠如 | コントローラ・モデルの先頭に「このファイルの説明文」がない | SafetyPatrolController.php` 等全般 |
| インラインスクリプト | index.blade.phpの flash メッセージ消去処理がインライン<script>内に記述 | index.blade.php` L26-35 |
1.【安全パトロール】コードの健全性検証
1.セキュリティ・脆弱性
エラーメッセージ漏洩
safetyPatrolController.php:210
php
// 現状:例外メッセージをそのまま返している
return response()->json([‘success’ => false, ‘message’ => ‘システムエラー: ‘ . $e->getMessage()]);
PHPの例外メッセージ(DBパス・APIキー名・内部構造等)がそのままフロントエンドに露出する
修正
php
// 固定文言に変更
return response()->json([‘success’ => false, ‘message’ => ‘システムエラーが発生しました。時間をおいて再試行してください。’]);
// ログには詳細を記録
\Log::error(‘AI checklist generation error: ‘ . $e->getMessage());
1-2.ファイルアップロードのバリデーション欠如
SafetyPatrolController.phpstore()
php
// 現状:バリデーションなしで直接 store()
$filePath = $request->file(‘attached_file’)->store(‘patrol_files’, ‘public’);
ファイルタイプ・サイズ制限がないため、実行ファイルや大容量ファイルのアップロードが可能な状態
修正
php
$request->validate([
‘attached_file’ => ‘nullable|file|mimes:pdf,jpg,jpeg,png,gif,webp|max:10240’,
‘patrol_datetime’ => ‘required|date’,
‘inspector_name’ => ‘required|string|max:100’,
]);
1-3.CSP方針違反 インラインイベントハンドラ
CLAUDE.md に「`onclick=””等のインラインハンドラを使わず、必ず `addEventListenerで登録する」と明記されているが、以下の箇所に違反が存在する
| ファイル | 行 | 内容 |
|---|---|---|
| show.blade.php | L105, L109, L113, L117 | onchange=”updateRowColor(…); autoSave()” |
| create.blade.php | L82 | onclick=”runAiProcess(…)” |
| index.blade.php | L43, L47, L51, L103, L115 | onclick=”window.location.href=…” |
修正方針:** 各ボタンに `data-url属性を付与し、外部JSで `addEventListenerに移行
2.データ喪失リスク
SafetyPatrolController.php destroy()` メソッド
php
// 現状:attached_file_path のみ削除
if ($patrol->attached_file_path) {
Storage::disk(‘public’)->delete($patrol->attached_file_path);
}
$patrol->delete();
// → safety_patrol_photos テーブルのレコードと画像ファイルは残存
パトロール削除時に、紐づく写真ファイル(storage/public/patrol_photos/)とDBレコードが削除されない。時間とともにストレージを圧迫する
php
// 写真ファイルとレコードを先に削除
$patrol->safetyPatrolPhotos()->each(function ($photo) {
Storage::disk(‘public’)->delete($photo->file_path);
$photo->delete();
});
$patrol->delete();
雨のみなと公園 コードのレビュー
台風の接近で朝からかなりの雨です・・・甲斐犬のキクの散歩は予定通り、上下に登山用のレインコートを着込んで散歩、でも40年前のゴアテックスは効果が薄く、かなり浸み込んできました・・・やはり、新しいのを使わないと大雨は無理かな


環境側面であるコードのレビューを実施した
\environment\edit_environment.blade.php
\environment\index.blade.php
1.最優先:CSPとインラインハンドラの矛盾
これが一番の地雷です。直近で@alpinejs/cspに移行してscript-srcから unsafe-eval を外したのに、1-1.この2画面はインラインイベントハンドラだらけonclick=”openAiModal()” / “closeAiModal()” / “runAiEstimate()”
onclick=”addCustomRow()” / “removeCustomRow(this)”
onclick=”window.print()”
script-srcからunsafe-inlineも外す方針なら、これらは全滅
Alpineだけ対応しても、素のonclickが残っていればCSPの一貫性は崩れる・・セキュリティ監査を目標にするなら、unsafe-inline除去は通過点になるはずなので、ここはaddEventListener方式へ統一すべき・・幸い既に477〜492行で同パターンを使っているのでdata-action=”open-ai-modal”のような属性+委譲リスナーに寄せれば機械的に直せる
元宇品の散歩
建設アシストのコードのセキュリティ対策として、CSP(Content Security Policy)でunsafe-evalを禁止した結果、Alpine.js の式評価がブロックされ動作不能になった問題を解決します
1.パッケージ切り替え・ビルド設定
package.json / resources/js/app.js
| 変更内容 | 詳細 |
| alpinejs → @alpinejs/cspに差し替え | npm install @alpinejs/cspを実行、app.jsのインポートを変更 |
| グローバル Alpine コンポーネントを app.jsに集約 | alpine:initイベント内で Alpine.data()を登録 |
app.jsに登録したグローバルコンポーネント:
| コンポーネント名 | 用途 |
| scheduleInitModal(chartType, switchUrl) | 工程表 初期選択モーダル |
| flashMessage | プロフィール保存後フラッシュメッセージ(2秒フェードアウト) |
| dropdownMenu | ナビゲーション ドロップダウン |
| laravelModal(initialShow, modalName, focusable) | Breeze 標準モーダル(フォーカストラップ付き) |
メインパソコンのエラー
甲斐犬のキク
元宇品の森を歩く
キクと朝の散歩
天狗城山に登る
2022/10/22 キクと一緒に天狗城山を登ったのが最後で4年間ほど、ご無沙汰・・・天狗城山は一気に約300mを登るの岩山・・・2022年の時も体力は無く登りに90分もかかっていた・・・それから前立腺癌のホルモン治療で体調がおかしくなり、筋肉も落ちて、膝の関節炎となり、歩くのもままならず、出張での駅の階段などは苦行で・・山などはとんでもない状態だった
そんな状態から最近は少し回復をして散歩もかなりの距離が歩けるようになっていた・・・何となく昼から、急に思い立ち甲斐犬のキクを連れて登る・・・膝も万全ではないので無理はできないが、休み休み上って、今回は山頂までは70分程、2021年の頃は40~50分ほどで登っていた・・・さすがに関節炎になってからは登れないと思っていたが、少し膝も回復して意欲も戻ってきたようだ・・・下りは転倒しないように注意して(ほとんど岩山は尻を落として下る)、ようやく車まで戻る
少しすると足の脛が痛い・・・登山をすると痛かったあの感覚は久しぶりだ
朝はキクと宇品を往復
厨房の仕切りを改修
雨の日曜日

朝から少しづつ降り出した雨は、昼頃から本降りの雨となって夜半まで降り続く・・・朝は、キクと元宇品の森を散歩で歩く、日曜日なのでマラソンする人や、犬の散歩など多くの人が来ていて、灯台の駐車場は満車の状態・・・散歩の帰りには、ガソリンが警告灯が付いたので、四国の旅行で給油したときから給油していない・・忘れないうちにスタンドで給油、まだガソリンは¥157と安かった
昼前に買い物に行き、明日の厨房の大工仕事のため、木材を購入する
昼からは、ネットワーク工程表のアプリケーションを作成する・・・やはりネットワーク工程表は中々難しいが、Claudeが手助けしてくれるが、難しい依頼はトークンの消費が激しく、クレジットの要求がすぐ来るので、使い方は考えながらする必要がある
夕方には、ほぼ納得できるような工程表が作れるアプリケーションが出来上がった・・・実際に入り色な工程を作成して調整してゆく必要があるが、問題は印刷のスケールをどのように調整するかが当面の課題、ネットワークがうまく表現できない

































































