今朝も暑い、キクを連れて元宇品を散歩、キクはタヌキを見つける・・・走りすぎてバテてました・・・午前中に、J58の車検に、無事に終わって、今回はブレーキオイルを入れ替えたので￥5万程、昼からNGIさんが訪ねて来て久しぶりに雑談
コメントはありません
Jeepの車検
タグ: 建設アシスト
日赤の定期診断 CodeX（GPT-5.6 Sol）
今日は3か月ごとの定期診断と栄養指導で、広島日赤病院に朝から、血液を採取して診断、前回は血糖値が悪かったが、今回は改善していた・・夕食を減らして、体重を2㎏程減量した効果が出たようだが、クレアチンは少し高くなっていた・・まあ、ほとんど体調は変更なしということか
帰ってから、ログイン画面から会社概要への遷移が気に入らなかったので、修正して、会社概要ページを大幅に修正する・・ここに内部監査の計画及び実施状況をまとめる予定で、スペースを開けておく
Claude Fable5の試用期間が20日まで再び延長となった・・・OpenAIのGPT5.6のリリースで競争が激しくなった結果のようだ・・・GPT5.6はSol / Terra / Lunaのクラスがあり、Solは、Claude Fable5と同じ性能のようだ、GPT5.6のCodexはコーディング作業を支援する製品・エージェントという位置づけが明確になり、Claude Codeのプラグインとして使用できる
Claude Code（要件整理、設計、実装、リファクタリング）
Codex（セキュリティレビュー、バグ検出、性能改善）
さっそくClaude CodeにcodeX 5.6 solをプラグインで使えるように、指示してインストールを任せて、それと同時にChatGPTを無料版からPlusの有料版に切り替え、Claude CodeへのCodeXプラグインの設定は、便利なのもので調べる必要はなくすべてClaude Codeが以下のように実施してくれる
- Codex CLI更新: 0.130.0 → 0.144.4（GPT-5.6対応版）
- config.toml設定: C:\Users\syste.codex\config.toml の先頭に2行追記、model = “gpt-5.6-sol”、model_reasoning_effort = “medium”
- 既存の設定（プラグイン・trust設定）は無変更です
- 動作確認: テスト実行でヘッダーに model: gpt-5.6-sol / OpenAI Codex v0.144.4 を確認し、正常に応答が返りました
Claude Codeのcodexプラグインはモデル未指定時にconfig.tomlのデフォルトを使うため、今後 /codex:rescue やレビュー依頼はすべてSolで実行されます。推論の深さを変えたい場合は model_reasoning_effort を low / high に変更できます。
| /codex:rescue | メインの依頼コマンド。調査・修正・実装タスクをCodex（GPT-5.6 Sol）に委譲 |
| /codex:review | 現在の変更をCodexにレビューさせる |
| /codex:adversarial-review | より厳しい敵対的レビュー |
| /codex:status | 実行中ジョブの状況確認 |
| /codex:result | バックグラウンドジョブの結果取得 |
| /codex:cancel | 実行中ジョブの中止 |
| /codex:setup | CLI接続確認・設定 |
普段使いは /codex:rescue に続けて依頼内容を書くのが基本です。例：/codex:rescue 工程表の印刷でヘッダーがずれる原因を調査して
また、コマンドを打たなくても、会話の中で「これはCodexに調査させて」「Codexで直して」と指示してもらえれば、こちらからCodexエージェントを起動して結果を報告します。どちらでも同じSolが使われます
キクと散歩 工事一覧の変更
システムログインでは、最初に会社概要に遷移し、工事一覧と進んでいたが、最初に工事一覧へ遷移するように切り替え、工事一覧のデザインを変更して、工事のサムネイルが表示されるようにした・・・バタバタと変更するが、じっくり見るとボタンの配置が雑多なので、少し変更することにする
元宇品の森を歩く ユーザー管理の検証
ユーザー管理検証
1.ユーザー管理・基盤是正の検証とリリース
今回反映された機能
- パスワードリセットのレート制限復活
- ログの日付別ファイル化（info・30日保持）※本番.envも書き換え済み
- パスワード強度10文字以上・英数字必須（日本語エラー）
- ユーザー無効化（is_active）＋ログイン中セッション即時遮断
- 認証ログauth_logs（ログイン失敗・ロックアウト・無効化ブロック）
- 仮登録トークン72時間二段期限（承認時再セット）
2.検証中に発見・修正したmain由来バグ（3件）
検証したからこそ見つかった、以前から存在した問題:
- 新IPログイン通知メールが未捕捉 — メールサーバー障害時、初IPユーザーが全員ログイン500になるリスク → try-catch＋警告ログ化
- 本登録リンクの無効/期限切れメッセージが非表示 — redirect(‘/’)経由でメッセージが捨てられていた → ログイン画面のメール欄下に表示
- パスワードリセット画面のルート喪失 — 「パスワードをお忘れですか」リンクが非表示になり機能の入口が無かった → ルート復活（既知テスト失敗も1件解消）
3.追加実施
- 認証まわりの日本語化: リセット画面・リセットメール本文・ログイン失敗/ロックアウトメッセージ（lang/ja.json・passwords.php・auth.php新設）
- パスワード変更専用ページ: 既存の/profileが導線ゼロで放置されていたのを発見。パスワード変更専用に改修し、ヘッダー右上に「PW変更」ボタンを設置。自己退会・自己情報変更はルートごと廃止（405）し、管理者経由＋is_active無効化運用に一本化
4.検証で手間だった点と今後の改善
- メール確認: Mailtrap接続切れ→MAIL_MAILER=log化→メール本文がLOG_LEVEL=infoで消える、と二段のハマり。今後はローカル検証開始時にstorage/logs/mail.logの動作確認を最初にやる
- 「操作したつもりが反映されていない」事例が2回（更新ボタン未押下・ログイン済みウィンドウでのログイン試行）。検証はDBの記録とセットで確認するのが確実（今回はその方式で全件裏取りした）
- 419/500エラーは検証の中断ポイントになった。今後の検証手順書には「必ずCtrl+F5してから操作」を明記する
5.残課題（別起票）
- 既知テスト失敗5件（logout外部リダイレクト・パスワード確認・registration無効化×2・トップ302）
- script-srcの’unsafe-inline’除去（別フェーズ）
- フェーズ1候補: login_successのauth_logs統合・activitylog・SoftDeletes・uncompromised()・2FA
テスト基準（今後の比較用）
92パス / 5失敗（失敗はすべて上記の既知5件）。mainは 8e3b354
VFKさんが来る 建設アシスト 品質・セキュリティ改善 総括
朝は京橋川を散歩させて、シャワーを浴びて五日市の病院に、帰りに元宇品の森でキクを散歩させていたらVFKさんから電話、昼は近くの『はる』でお好み焼きを食べて、晩秋には北海道へJeepでキャラバンすることで盛り上がる・・・夕方に、贈り物がしたいということなので、洋酒の酒店に行く、ウイスキーが好みだそうで2種類を購入、TAMにも一本贈り物として頂いた
建設アシスト 品質・セキュリティ改善 総括
1.目的
建設アシストは、現場マネジメントDXの実践アプリケーションで、本プロジェクトの目的は以下の3点
- 大手組織のセキュリティ審査に耐えるシステムにする 複数テナント（会社）が同居するSaaSとして、テナント間のデータ分離を構造的に保証する
- AIに投げる情報の管理と漏洩リスクの低減 工事情報・現場情報をAI APIに送信する以上、何をどう送り、何を記録するかを一元的に管理できる構造にする
- 今後の機能追加に耐える保守性の確保 一人開発で継続的に機能を追加していくため、重複コード・デッドコードを排除し、「1箇所直せば全体に効く」構造を作る
2.出発点の課題（Fable 5による全体検証の結果）
セキュリティ（フェーズ1）
- Critical 7件・High 12件。中心はIDOR（他社データへの越境アクセス）で、工程表・安全パトロール・RA・施工計画書の主要機能に集中していた
- テナント分離がコントローラの手動認可（authorizeProject）に全依存しており、
1箇所の実装漏れがそのままデータ漏洩に直結する構造だった - 当時の評価:「現時点では大手組織のセキュリティ監査に耐えられない」
保守性（フェーズ2）
- AI呼び出しが8箇所に散在し、URL・タイムアウト・エラー処理がコピペ重複
- 工程表のJS約4,100行がBladeにインラインで埋め込まれ、CSP強化の障害に
- テナント設計が未完了のモデル（company_id未設定）が多数
- デッドコード（未完成のWord/Excel出力サービス、旧版施工計画書、孤立したAIサービス等）が大量に残存。
バグ（フェーズ3）
- 確定バグ14件。空CSVで法規制マスタが全削除される致命的バグ、工程表の無限ループ、祝日計算誤りによるCPMの1日ズレ等
- トランザクション欠落が主要機能に多数（途中失敗で中途半端なデータが残る）
- 同時編集の保護が皆無（後勝ち上書きで先の編集が無警告で消える）。
夕方に湯田温泉へ
建設アシストアプリケーションをマルチテナントSaaSとして「他社のデータは存在自体が見えない」状態を全モデルに実現する作業をする・・設計上の重要ポイントとして、グローバルスコープ単体ではなく、既存のIDOR(Insecure Direct Object Reference：URLのIDを書き換えて、他人のデータにアクセスする攻撃)対策トレイト（AuthorizesTenantAccess）と二重防御になっている。仮にどちらか一方に穴があっても、もう一方が守る構造で、これが大手組織のセキュリティ監査に耐えられる根拠になる
■会社IDを直接持つ主要モデル10個に、自動テナント絞り込みを適用
| 分類 | 対象モデル例 | 絞り込み方式 |
|---|---|---|
| 直接持ち | User, Project, Department など7モデル | WHERE company_id = 自社 |
| NULL＝全社共通 | テンプレート・プリセット系3モデル | WHERE company_id = 自社 OR NULL |
■途中で発覚した重大問題と解決：User モデルにスコープを適用した直後、ログイン後の画面でメモリ枯渇エラーが発生・・・原因は無限再帰
■Project配下・監査計画配下のモデル13個に適用。これらは company_id を直接持たず、親テーブル経由で絞り込む
実データで確認した効果の例
| モデル | スコープ前 | スコープ後 |
|---|---|---|
| ProjectEnvAspect | 241件（他社75件含む） | 166件（自社のみ） |
| ProjectCondition | 49件（他社23件含む） | 26件（自社のみ） |
■最終状態
テスト：TenantIsolationTest 31パス（38 assertions） 対象：A分類10 ＋ B分類13 ＝ 計23モデル完了
Claude Fable5でシステムの検証
今日は雨の日曜日・・・現在最高性能を持つというAIのClaude Fable5が、6/1に提供されたが6/5には提供禁止となってしまった、7/1から再び提供されて、7/7まで使えるという・・・これは、是非とも一番課題で問題が多いシステム全体の成熟性を確認しなければ、熱も下がって少し調子も上がったので、さっそく取り掛かる
0.前提条件
- まずFable5には修正・削除・リファクタリングは一切行わなず検証を実施する
- 対応済みの事項は以下の内容（再確認は必要）
- AuthorizesTenantAccessトレイトによるコントローラのテナント認可
- SecurityHeadersMiddleware、HTTPS 強制、セッション強化、不審ログイン検知
- CSP 対応の途中経過（インラインイベントハンドラの addEventListener 化、@alpinejs/csp 採用）
1.作業フェーズ
- フェーズ1: セキュリティ検証（ファイル別）
- フェーズ2: 保守性・コード品質の改善提案（全体）
- フェーズ3: バグおよびバグの可能性の検出（全体）
2.フェーズ1: セキュリティ検証
2-1. 検証観点（チェックリスト）
A. テナント分離（最優先）
- クエリに tenant_id 等のスコープ漏れがないか（Eloquent 直接呼び出し、find($id)、DB:: 生クエリ含む）
- AuthorizesTenantAccess トレイトの適用漏れコントローラ・メソッド
- ルートモデルバインディングでの他テナントリソース参照可能性（IDOR）
- グローバルスコープの回避箇所（withoutGlobalScopes 等）の妥当性
B. 認証・認可
- ミドルウェア（auth, verified 等）の適用漏れルート
- Policy / Gate 未適用のまま操作可能なアクション
- 権限昇格の可能性（ロール判定の抜け）
C. 入力検証・インジェクション
- バリデーション未実施・不十分なリクエスト処理
- SQL インジェクション（whereRaw, DB::raw, DB::select 等の変数連結）
- マスアサインメント（$fillable/$guarded の不備、$request->all() の直接渡し）
- パストラバーサル（ファイルパスにユーザー入力を使用している箇所）
D. XSS・出力エスケープ
- Blade の {!! !!} 使用箇所の妥当性
- SVG ダイアグラムエディタ（約3,600行の JS）: ユーザー入力の SVG/DOM への挿入方法（innerHTML、属性直接代入等）、保存された SVG データの再表示時のサニタイズ
- リッチテキストバー（RTB）経由の HTML 挿入のサニタイズ
E. CSP 対応
- 残存するインラインイベントハンドラ（onclick 等）・インライン script/style
- SecurityHeadersMiddleware の CSP ディレクティブの妥当性（unsafe-inline / unsafe-eval の残存有無）
F. CSRF・セッション・Cookie
- CSRF 保護の除外ルート（$except）の妥当性
- Ajax/fetch 呼び出しの CSRF トークン付与漏れ
- セッション・Cookie 設定（secure, httponly, samesite）と Xserver リバースプロキシ構成（TrustProxies）との整合
G. ファイルアップロード
- 拡張子・MIME タイプ検証、サイズ制限
- 保存先（public 直下への保存有無）、実行可能ファイルの拒否
- ダウンロード時のテナント認可
H. 情報漏洩
- ログ・例外メッセージへの機密情報出力
- .env 値のハードコード、デバッグコードの残存（dd, dump, console.log の機密出力）
- API レスポンスの過剰な属性返却（Resource 未使用でのモデル直接返却）
I. 依存パッケージ
- composer audit および npm audit を実行し、既知脆弱性を報告する（アップデートは実施しない）
3.フェーズ2: 保守性・改善提案
3-1. 検証観点
- 重複コード: コントローラ・JS 間の重複ロジック（サービスクラス / 共通モジュールへの抽出候補）
- 肥大化: 長大なコントローラメソッド・Blade ファイル・JS ファイル（特に SVG エディタ約3,600行の分割方針）
- 命名・構成: Laravel 標準構成からの逸脱、命名の不統一（日本語/英語混在の規則性含む）
- 設定のハードコード: config/env に逃がすべきマジックナンバー・文字列
- テスト: 自動テストのカバレッジ状況、テナント分離・認可まわりのテスト欠落箇所
- フロントエンド: Blade 内 JS の構造（モジュール化、イベント委譲の一貫性、Alpine.js との役割分担）
- DB: マイグレーションとスキーマの整合、インデックス欠落（tenant_id 複合インデックス等）、N+1 クエリ
- ドキュメント: CLAUDE.md / README の実態との乖離
4.フェーズ3: バグおよびバグの可能性
4-1. 検証観点
- 明確なバグ: 未定義変数・null 参照、型不整合、到達不能コード、条件式の誤り（=/==/=== 等）
- JS 側: SVG エディタのイベントリスナー解除漏れ（メモリリーク）、tblMergeCells/tblSplitCell 等テーブル操作の境界条件、undo/redo の状態不整合、非同期処理の競合
- 境界条件: 空配列・null・0件データ時の挙動、日付境界（年度・和暦処理があれば特に）
- トランザクション: 複数テーブル更新時のトランザクション欠落、失敗時のロールバック不備
- 並行性: 同一テナント内の同時編集での上書き・競合（楽観ロックの有無）
- 環境差異: MariaDB（ローカル）と MySQL（本番）の差異に起因する潜在問題、Xserver 固有設定への依存
- エラー処理: try-catch の握りつぶし、失敗時にユーザーへ誤った成功表示をする箇所
5.実行手順
- リポジトリ構成を把握する（app/, routes/, resources/views/, resources/js/, database/, config/, public/ を中心に全体を読む。vendor/, node_modules/ は除外）
- フェーズ1を実行し、レポートを出力して停止・確認を待つ
- 承認後フェーズ2を実行し、レポートを出力して停止
- 承認後フェーズ3を実行し、レポートを出力して完了報告
- 各フェーズの完了報告には「検証したファイル数」「読み飛ばした箇所とその理由」を必ず含める（検証の網羅性を判断できるようにするため）
F1.セキュリティ検証レポート（フェーズ1）
F1-1.検証規模
- コントローラ: 約40ファイル / モデル: 約50ファイル / Blade: 約168ファイル / ルート: 3ファイル / サービス: 8ファイル
- 検証観点: A テナント分離 / B 認証・認可 / C 入力検証・インジェクション / D XSS / E CSP / F CSRF・セッション / G ファイルアップロード / H 情報漏洩 / I 依存パッケージ
F1-2.指摘件数（重大度別）
| 数 | 主な内容 | |
|---|---|---|
| Critical | 7 | クロステナント IDOR 群（工程表・安全パトロール・RA・施工計画書）、CSP unsafe-inline + 保存型XSS の複合、phpspreadsheet SSRF/RCE |
| High | 12 | テンプレート認可欠落、機密ファイルの public 保存、保存型XSS（図面/AI-HTML/style属性）、依存パッケージ High、-tmp/_old ファイルのオートロード混入 |
| Medium | 15 | Mass Assignment、例外メッセージ露出、グローバルマスタ越境、パストラバーサル、Secure Cookie 未設定 等 |
| Low | 多数 | 多層防御・推奨改善（代表例＋件数で集約） |
F1-3.総評
- 全モデルにテナント用グローバルスコープ（BelongsToTenant 等）が存在せず、テナント分離は各コントローラの手動 authorizeProject() に全面依存している。
- そのうえ authorizeProject() は「Project が自社か」しか見ず、ネストした子リソース（schedule / patrol / riskAssessment / item）の親一致を検証していないメソッドが多数あり、Route::scopeBindings() も未使用。結果として「自社の Project ID + 他社の子リソース ID」を URL に並べるだけで他テナントのデータを閲覧・改ざん・削除できる Critical な IDOR が7系統存在する。
- 加えて CSP に script-src ‘unsafe-inline’ が残存し、図面ノード・AI整形HTMLがサーバー側サニタイズなしで保存・再表示されるため、保存型XSSが現実的に成立する。
一方で、認可が正しく実装されているコントローラ群も多く（ProjectPlan / Audit 系 / CompanyAdmin など）、修正パターンは「authorizeProject() の追加 + 子リソースの親一致 abort_if の2行」と明確です。恒久対策として Route::scopeBindings() の全面適用とグローバルスコープ導入を行えば、監査耐性は大きく向上します。
F2.保守性・改善提案レポート（フェーズ2）
F2-1.テナント設計の未完了モデル洗い出し
重要な前提: 本アプリには BelongsToTenant 相当のグローバルスコープ（addGlobalScope）は1つも存在しない。テナント分離はすべてコントローラ内の手動 where(‘company_id’, …) / authorizeProject() に依存している。既存の booted()（BarTask / NetworkNode / NetworkArrow）は front_id(UUID)採番専用でスコープではない。したがって下表の「グローバルスコープ」列は全モデル「未実装」。
テナント到達経路: 子テーブルは company_id を持たず、project_id → projects.company_id（または schedule_id → schedules.project_id、audit_report_id → audit_plans.company_id 等）の多段リレーションでのみテナントを特定できる。
F2-2.観点: 重複コード
- 【高】Anthropic API 呼び出しの8重複（CLAUDE.md「AI推論は共通コード」ルール違反）
- 【高】テナント認可の二重方式（トレイトがあるのに手書きが残存）
- 【中】★ CSV入出力ロジックの6重複
- 【中】Docx/Xlsx出力の二系統併存（デッドコードの懸念）
- 【中】フロントエンド fetch/CSRF/モーダル制御の重複
F2-3.観点: 肥大化
コントローラ行数 Top10（実測）
| 数 | ファイル |
|---|---|
| 1548 | ConstructionPlanController.php |
| 952 | ProjectPlanController.php |
| 865 | NetworkScheduleController.php |
| 687 | SafetyPatrolController.php |
| 573 | EnvironmentController.php |
| 432 | RiskAssessmentController.php |
| 392 | BarChartController.php |
| 350 | ChecklistController.php |
| 313 | UserController.php |
| 251 | CompanyAdminController.php |
【高】Blade巨大ファイル（インラインJS肥大）
| 数 | ファイル | 特記 |
|---|---|---|
| 3082 | schedules/network.blade.php | 単一<script> が724-3080の約2356行 |
| 2439 | schedules/barchart.blade.php | 同様の巨大インラインJS |
| 1875 | projects_plan/edit_section.blade.php | @push(‘scripts’)＋diagram-editor-script include＋openCtxMenu上書きIIFE |
| 854 | environment/edit_environment.blade.php | |
| 729 | projects_plan/setup.blade.php | 対応 setup.js(392行)は分離済み＝良い前例 |
- 提案: network / barchart の巨大インラインJS を resources/js/schedules/network.js・barchart.js に外部化（setup.js の前例に倣う）。CSP unsafe-inline 除去の前提条件でもある。
- 想定作業量: 大 → 別途計画が必要
【中】SVGダイアグラムエディタ群（実測 計4172行）の再分割
既に責務別5分割済み（良い設計）だが個別ファイルが肥大:
| 数 | ファイル | 責務 |
|---|---|---|
| 1541 | diagram-editor-nodes.blade.php | ノードCRUD/RTB/画像/線ノード |
| 1132 | diagram-editor-table.blade.php | 表/Excel貼付/xspreadsheet |
| 726 | diagram-editor-ui.blade.php | 右クリック/保存/ページ/テンプレ/印刷 |
| 602 | diagram-editor-connect.blade.php | コネクタ/接続線ダイアログ |
| 154 | diagram-editor-core.blade.php | 状態/Undo-Redo/グリッド |
施工計画書の再構築 Claude Fable 5の話
今週はほとんどの時間を施工計画書の再構築で費やした・・・自由に表や画像およびテキストをキャンバスに配置して、計画書をつくることは難しい・・・結局、色々試したが、使い慣れたVisio的な画面操作で作成することにした・・・作成はやはり、かなり難易度が高く、構築指示も何回も失敗したが、さすがにClaude Code、最後は何とか意図する内容にまとめてくれた
これから、実際に施工計画書を作成して、効果的なテンプレートをつくりながら、システムの使い勝手を検証してゆく
世界中のあらゆるサーバーはハッキング出来ると恐れられ、提供が中止されていたClaude Mythosに、安全フィルターが施されたClaude Fable 5が提供させるようになった・・・6/22まではトークンは消費（2倍）されるが、無料で使うことができるようになっていた・・・この間にシステム全体の診断をさせようと思っていたら、開始から3日目でUSAからの指示で提供が禁止（アメリカ国民以外は使用禁止・・だが、区別ができないので全世界で禁止となった）されてしまった・・・これからのAIの使い方に新しい波がやってくる予感
京橋川の土手を散歩 施工計画書再構築
施工計画書 セットアップ画面 再構築
resources/views/projects_plan/setup.blade.php を中心に、セットアップ画面の右パネルを大幅改修・・・手直しではなく作り直しに
1.変更ファイル一覧
1-1.マイグレーション（新規）
database/migrations/2026_06_13_000001_add_margin_to_project_plans_table.php
project_plans テーブルに余白カラムを追加margin_top（上余白 mm、デフォルト25）margin_bottom（下余白 mm、デフォルト25）margin_left（左余白 mm、デフォルト25）margin_right（右余白 mm、デフォルト20）
1-2.ルート追加（routes/web.php)
| メソッド | URL | 名前 | 用途 |
|---|---|---|---|
| PATCH | {plan}/settings| | project_plans.update_settings | 全体一括保存 |
| POST | {plan}/change-work-type | project_plans.change_work_type | 工事種別変更 |
| POST | {plan}/sections | project_plans.sections.store | セクション追加 |
1-3.コントローラー（app/Http/Controllers/ProjectPlanController.php）
- 建築系セクション定義を24項目に更新（総合施工計画〜給排水衛生工事）
- updateSettings() 追加：ヘッダー/フッター・余白・セクション並び順/名前を一括保存
- changeWorkType() 追加：工事種別変更（既存セクション全削除 → 新規種別で再作成、JSONで新セクション一覧を返す）
- addSection() 追加：カスタムセクション追加
墓参り 工事管理の見直し
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();
雨の竜王公園を散歩 アップロード画像の縮小
朝から雨が降り続ける日曜日、娘たちを送って、また迎えに行く・・・今日はお隣が地鎮祭
建設にアップする画像の軽量化のルーチンを組み込んで、DBに取り込む画像の軽量化を図る
画像アップロード共通化・圧縮対応
1.概要
システム全体の画像アップロード処理を共通サービス化し、GDライブラリによる圧縮・リサイズを追加した
2.対象箇所の調査結果
| コントローラー | メソッド | 最大 | ストレージパス |
|---|---|---|---|
| CompanyAdminController | uploadLogo | 5MB | company_logos/ |
| ProjectController | uploadPhoto | 50MB | photos/ |
| ChecklistController | uploadEvidence | 50MB | evidence/ |
| ConstructionPlanController | uploadItemImage | 5MB | plans/{id}/images/ |
| ConstructionPlanController | uploadTemplateImage | 5MB | templates/images/ |
| SafetyPatrolController | storePhoto | 10MB | patrol_photos/ |
以下は非画像混在・CSV等のため対象外とした：
- RiskAssessmentController（Excel/Word/PDF/Image混在）
- SafetyPatrolController::store（PDF/Image混在、圧縮不可のPDFが主）
- AdminController, AuditMasterController, EnvironmentController, IsoClauseController（CSVのみ）
元宇品の散歩 環境側面の見直し
法規制の特定を見直したので、同じような処理をしている環境側面の特定方法も修正する
今まで特定のための検索条件を工事概要から実施していたが、法規制の特定で作成した工事に関する条件DBを共有化、項目追加することに変更する・・・また、フロントエンドも法規制と同じようにする
| 質問 | 回答 |
|---|---|
| 条件保存方式 | project_conditions` テーブル新規作成。環境側面モーダルの条件も同テーブルに登録 |
| AI軽量化 | 今回は対象外。次のステップとして実施 |
| edit_overview の廃止範囲 | ☑ボックスで設定した内容を概要欄に転記する機能をすべて廃止。テキストボックスのみに変更 |
| @section(‘extra_tabs） | 環境側面編集画面のみで使用。他ページへの影響なし |
1.edit_overview.blade.php の変更
1-1.廃止する要素
現在のファイルは3エリアで構成：
| エリア | 内容 | 対応 |
|---|---|---|
| エリア1（上部） | textareaとフォーム | 残す |
| エリア2（中央） | 「選択した項目を概要に追加する」ボタン | 残す |
| エリア3（下部） | チェックボックス群（工事種別・立地条件・工事規模・工事の特性・仮設設備等） | 削除 |
雨の散歩 法規制の再構築コーディング開始
1-3.更新ファイル
app/Models/Regulation.php ← $fillable 新カラム追加
app/Http/Controllers/ChecklistController.php ← 全面再構築
app/Http/Controllers/AdminController.php ← CSV新フォーマット対応
resources/views/components/eval_modal.php ← deleteEvidence URL修正
resources/views/layouts/footer.blade.php ← z-50 → z-10（モーダル被り解消）
routes/web.php ← conditionMatchルート追加・deleteEvidenceルート修正
法規制特定のコードの問題点が洗い出せたので、Excelシートをもう一度、見直しと再構築をして、いよいよコードを作成する
1.法規制特定機能 再構築（Step 1〜8）
1-1.概要
edit_Laws_Regulations.blade.phpとindex.blade.phpを指示書に従い全面再構築した
1-2.新規作成ファイル
database/migrations/
2026_06_05_095137_add_select_columns_to_regulations_table.php
2026_06_05_095150_add_source_to_checklist_results_table.php
2026_06_05_112359_add_unique_index_to_checklist_results_table.php
app/Services/
RegulationMatcherService.php
resources/views/
components/laws_condition_modal.blade.php
Laws_Regulations/edit_Laws_Regulations.blade.php ← 新設計版
Laws_Regulations/index.blade.php ← 新設計版
Laws_Regulations/_tab_bar.blade.php ← 共通パーシャル
キクと散歩 法規制コードの3回目の修正
checklist_results （プロジェクト別選択結果）
※課題：保存は全件DELETE → INSERT の洗い替え方式
| カラム | 型 | 役割 |
| project_id | FK | 現場 |
| regulation_id | FK | 法規制 |
| is_checked | boolean | 適用/非適用 |
c
法規制のコードを見直しを始めた・・・まずは現状分析
１．現在のテーブル構成
regulations`（法規制マスタ）
※課題：ai_description1列に「キーワード」と「制御フラグ」を混在させている
| カラム | 型 | 役割 |
| id | PK | — |
| parent_id | FK(self) | 親=null、子=親ID（2段構造） |
| group_code | string | 法律名（主に親） |
| ref_law | string | 関係条文（主に子） |
| action_conten | text | 実施すべき内容 |
| full_law_text | text | 原文（展開表示用） |
| ai_description | text | AI判定用キーワード（【選択必須】/【選択しない】制御フラグも兼用） |
| explanation_image | string | 解説画像 |
我が家の妻側が丸見え 労働安全衛生法のレビュー
建設アシストの法規制管理の見直しを貸しする・・これで2回目となる
それなりに満足できる法規制の特定とはなっているが、もう一度判定に使っているAIを検討した結果、AIに頼らず、条件選定で多くが可能なことが分かってきたので変更を検討するが、今まで法規制の解釈のためにベースとなる体系（Excel→CSVで取込）を見直しをする必要ができてきた
2回目も、かなり突っ込んできたが、途中でかなり妥協をしていたので、今回は腰を入れて見直しを開始する・・・やはり、安衛法の解釈は複雑、言葉の定義から、法規制と思っていたのが実は「ガイドライン」だったり、新しい発見も多い・・・1日をかけて約半分まで終わったが・・・疲れる
ここで、もう一度「元請」周りの安衛法による定義を確認する
| 呼称 | 意味 | 根拠 |
| 事業者 | 労働者を使用する者すべて（元請も下請も） | 法2条3号 |
| 注文者 | 仕事を他人に請け負わせる者（下に出せば中間業者も注文者） | 法31条等 |
| 元方事業者 | 一の場所の仕事の一部を下請に請け負わせている事業者＝元請（全業種共通） | 法15条1項 |
| 特定元方事業者 | 元方事業者のうち建設業・造船業（特定事業）のもの | 法15条1項 |
| 関係請負人 | 元方事業者の下のすべての請負人（一次・二次…下請全部） | 法15条1項 |
選任される「人」の呼称
| 呼称 | 誰が選任 | 役割 | 根拠 |
| 統括安全衛生責任者 | 特定元方事業者 | 現場全体の安全衛生を統括管理する人 | 法15条 |
| 元方安全衛生管理者 | 特定元方事業者 | 統括の管理事項のうち技術的事項を管理する人 | 法15条の2 |
| 店社安全衛生管理者 | 特定元方事業者（中小規模現場） | 店社（支店等）から現場を指導・巡視する人 | 法15条の3 |
| 安全衛生責任者 | 各下請（関係請負人） | 統括安全衛生責任者との連絡役 | 法16条 |
- 元方事業者（全業種）→ 法29条：関係請負人とその労働者が法令違反しないよう指導する義務。建設業ではさらに法29条の2で危険場所の技術的指導。
- 特定元方事業者（建設・造船）→ 法30条：統括管理措置。協議組織の設置・運営、作業間の連絡・調整、作業場所の巡視、関係請負人の安全衛生教育の指導・援助、仕事の工程・機械設備の配置計画と関係法令措置の指導、その他労働災害防止に必要な事項の6つです。
- 注文者（設備等を請負人に使わせる者）→ 法31条：足場・型枠支保工等の設備面の措置
雨のみなと公園 コードのレビュー
台風の接近で朝からかなりの雨です・・・甲斐犬のキクの散歩は予定通り、上下に登山用のレインコートを着込んで散歩、でも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”のような属性＋委譲リスナーに寄せれば機械的に直せる
iso_app 開発ロードマップ
1. プロジェクト概要
so_app は、建設会社の作業所管理をシステム化した業務アプリケーションです。ISO監査・施工計画・環境側面・リスクアセスメント・安全パトロール・法規制管理を統合した、建設DXを目指した詳細な管理システム
| 項目 | 内容 |
| 技術スタック | Laravel(PHP) + Vite + Tailwind CSS + SQLite/MySQL |
| AI機能 | Claude API(法規制選定・環境側面推論・監査支援) |
| モデル数 | 約45モデル(ISO監査・工事管理・環境・安全・リスクなど) |
| 現在の状態 | 複数社でテスト運用中 |
| 目標 | 建設業界のDX化 |
| 特徴 | セキュリティを重視した「統制下でのAI活用」の実証システム |
2. フェーズ別ロードマップ
Phase 1: 品質と信頼性の確立(現フェーズ)
| 作業 | 状態 |
| セキュリティ監査(Critical 1〜4 テナント分離) | ✅ 完了 |
| セキュリティ監査(High 7〜9 認可漏れ) | ✅ 完了 |
| AI送信情報のガード機構(InputValidator) | ⏳ 次タスク |
| AI送信内容の透明性確保(ユーザー画面への明示) | ⏳ 予定 |
| Medium 13 ファイル名処理 | ⏳ 予定 |
Phase 2: 保守性と共通化
| 今後作業 | 効果 |
| Blade コンポーネント化(写真・添付・印刷UI) | 新機能追加が高速化 |
| AI Service の共通基底クラス | AI呼び出しの一元管理 |
| PrintHelper・共通ヘルパー関数の整備 | 重複コードの削減 |
| トレイト化(HasPhotos, HasAttachments等) | モデルの統一化 |
| Policy への移行(Phase 3) | 認可の構造的解決 |
| グローバルスコープによるテナント自動分離 | 忘れて漏れる事故の防止 |
4. 直近のアクションアイテム
| 作業内容 | 対象ファイル | 状態 |
| InputValidator の実装(AI送信ガード機構) | app/Services/Ai/InputValidator.php | ⏳ |
| 既存AI Serviceへの組み込み(5箇所) | AiRecommendationService等 | ⏳ |
| Environment + RiskAssessmentへのトレイト確認 | 完了確認 | ✅ |
| ai_usage_logs テーブルの設計・作成 | database/migrations/ | ⏳ |
| プロンプトキャッシュの実装 | 全AI Service | 📅 |
| ログローテーション設定(.env変更) | config/logging.php | 📅 |
5. 業界への影響と目標
このシステムは「技術者が作った業務システム」ではなく、「業務実践者がAIを道具として使って作った業務システム」です。建設業界のDX化に向けて、特に以下の点で先進的な位置付けにあります
- ISO監査・施工計画・環境・安全・法規制管理の統合(業界で類を見ない)
- 「機密情報は外部AIに出さない」設計によるセキュリティと利便性の両立
- 大手企業の情報セキュリティ要件に対応可能な「統制下でのAI活用」の実証
- 30年以上の建設業務経験と20年のISO審査経験が詰め込まれた業務知識
今AIの活用に伴い、AIのセキュリティが大きな課題となっていますが、「AI使用禁止」ではなく、「適切な制御下での活用」という選択肢を具体例として示すことが目標とし、このシステムが業界全体のAI活用推進のモデルケースとなることを目指します
Phase 3: AIゲートウェイ・セキュリティ監視
| 今後作業 | 期待効果 |
| AI利用ログテーブル(ai_usage_logs)の実装 | コストの可視化・会社別分析 |
| コスト制御(予算上限・アラート)コスト制御(予算上限・アラート) | APIコストの自動管理 |
| ルールベース匿名化サービス | 機密文書の安全なAI活用 |
| セキュリティ監視Console Command | 日次自動チェック |
| セキュリティダッシュボード | 運用状況の可視化 |
| プロンプトキャッシュの実装 | APIコスト最大90%削減 |
Phase 4: 組織内AI・高度なセキュリティ
| 今後作業 | 内容 |
| Ollama + ローカルLLMの検証 | 自前AIの感触をつかむ(無料) |
| 契約書・技術文書の匿名化処理 | 機密情報を外部に出さない仕組み |
| 統合AIパイプライン | 匿名化→外部AI→復元の一連の流れ |
| AI利用の完全監査ログ | セキュリティ監査員AI |
| 管理ダッシュボードの高度化 | リアルタイム監視・異常検知 |
Phase 5: 商用化準備
| 今後作業 | 内容 |
| サーバーセキュリティの強化 | ファイアウォール・HTTPS・バックアップ |
| ユーザー管理のセキュリティ強化 | パスワードポリシー・2FA・セッション管理 |
| スケーラビリティ対応 | 複数社本格導入への対応 |
| SLA・サポート体制の整備 | 商用化に向けた運用体制 |
3. サーバー・ユーザー管理セキュリティ計画
3.1 ユーザー管理の強化(優先度高)
| 項目 | 内容 | 優先度 |
| パスワードポリシー | 複雑性要件・有効期限の設定 | 高 |
| ログイン試行回数制限 | ブルートフォース攻撃対策 | 高 |
| セッションタイムアウト | 一定時間後の自動ログアウト | 高 |
| 退職者の即時無効化 | アカウント無効化フローの整備 | 高 |
| 二要素認証(2FA) | 重要操作時の追加認証 | 中 |
| アクセスログ閲覧UI | 管理者向けの操作履歴確認機能 | 中 |
3.2 サーバーセキュリティ(段階的に対応)
| 項目 | 内容 | 難易度 |
| HTTPS の徹底 | SSL証明書の設定・自動更新 | 低 |
| 不要ポートの閉鎖 | ファイアウォール設定 | 中 |
| OS・PHP・Laravelのアップデート方針 | 定期更新のルール化 | 低 |
| バックアップ体制 | 自動バックアップの設定・復旧手順 | 中 |
| ログローテーション | 日次ローテーション設定(保存14日) | 低 |
| 依存ライブラリの脆弱性チェック | composer audit の定期実行 | 低 |
ログインに関するセキュリティ
1.ログインに関するセキュリティ
SaaS運用に向けたセキュリティ強化として、フェーズ1（必須項目）の完了およびフェーズ2の主要項目を実装した。
1-1. HTTPS強制（フェーズ1）
- iPadのChromeブラウザでログインフォーム送信時に「送信されている情報は保護されません」の警告が表示されていた。
- XサーバのSSL化は設定済みだったが、LaravelのURL生成がHTTPになっていた。
① `app/Providers/AppServiceProvider.php` に追記
“`php
use Illuminate\Support\Facades\URL;
public function boot(): void
{
if (!app()->environment(‘local’)) {
URL::forceScheme(‘https’);
}
}
② `bootstrap/app.php` にTrustProxies設定を追加
“`php
$middleware->trustProxies(at: ‘*’);
“`
結果
- iPadでの警告が解消された。
- ローカル環境（HTTP）では適用しない条件分岐を追加し、ローカルの動作も正常化。
1-2. セッションのセキュア設定（フェーズ1）
本番・ローカル各.envに以下を追記：
| 項目 | 本番 | ローカル |
| SESSION_SECURE_COOKIE | true | false |
| SESSION_ENCRYPT | true | true |
| SESSION_SAME_SITE | strict | lax |
結果
- セッションCookieのHTTPS限定送信を設定。
- セッションデータの暗号化を有効化。
- 既存ログインユーザーのセッションが一度無効化されたが、再ログインで正常動作を確認。
1-3. ログイン失敗のロック機構（フェーズ1）
app/Http/Requests/Auth/LoginRequest.php を確認した結果、Laravel標準のRateLimiterによる以下の機能がすでに実装済みであることを確認した。
- 5回失敗でアカウント一時ロック
- メール＋IPアドレスの組み合わせでカウント
- 時間経過で自動解除
- Lockoutイベントの発火
結果
- 追加実装不要。実装済みを確認。
1-4. セキュリティヘッダーの実装（フェーズ2）
app/Http/Middleware/SecurityHeadersMiddleware.phpを新規作成し、bootstrap/app.php` に登録。
設定したヘッダー：
| ヘッダー | 設定値 | 効果 |
| Strict-Transport-Security | max-age=31536000 | HTTPS強制をブラウザに記憶 |
| X-Frame-Options | DENY | クリックジャッキング防止 |
| X-Content-Type-Options | nosniff | MIMEタイプ誤判定防止 |
| Referrer-Policy | strict-origin-when-cross-origin | URL漏洩防止 |
| Content-Security-Policy | self + unsafe-inline | XSS対策 |
注意事項
- ローカル環境（APP_ENV=local）では全ヘッダーをスキップする条件を追加。
- TipTapエディタ・Axios使用のため、CSPは段階的に厳格化する方針とした。
1-4. セキュリティヘッダーの実装（フェーズ2）
app/Http/Middleware/SecurityHeadersMiddleware.hpを新規作成し、bootstrap/app.php` に登録。
設定したヘッダー：
| ヘッダー | 設定値 | 効果 |
| Strict-Transport-Security | max-age=31536000 | HTTPS強制をブラウザに記憶 |
| X-Frame-Options | DENY | クリックジャッキング防止 |
| X-Content-Type-Options | nosniff | MIMEタイプ誤判定防止 |
| Referrer-Policy | strict-origin-when-cross-origin | URL漏洩防止 |
| Content-Security-Policy | self + unsafe-inline | XSS対策 |
注意事項
- ローカル環境（APP_ENV=local）では全ヘッダーをスキップする条件を追加。
- TipTapエディタ・Axios使用のため、CSPは段階的に厳格化する方針とした。
1-5. 不審ログイン通知メール（フェーズ2）
新しいIPアドレスからのログインを検知し、登録メールアドレスへ通知メールを自動送信する機能を実装。
新規作成ファイル
app/Mail/SuspiciousLoginMail.php
resources/views/emails/suspicious_login.blade.php
resources/views/emails/suspicious_login_text.blade.php（HTML/テキスト両形式対応）
修正ファイル
app/Http/Controllers/Auth/AuthenticatedSessionController.php
検知ロジック：
$isNewIp = !LoginLog::where(‘user_id’, $user->id) ->where(‘ip_address’, $request->ip()) ->where(‘id’, ‘!=’, $log->id) ->exists(); if ($isNewIp && $user->email) { Mail::to($user->email)->send( new SuspiciousLoginMail($user, $request->ip(), now()->format(‘Y年m月d日 H:i’)) ); }
メール設定
| 環境 | 設定 |
| 本番 | Xサーバ SMTPサーバ（sv13426.xserver.jp:587） |
| ローカル | MAIL_MAILER=log（ログファイルに出力） |
動作確認結果
- Gmail：受信トレイに正常届を確認 ✅
- MSN（Outlook）：迷惑メールフォルダに届くことを確認 ✅
残課題
MSN/Outlookの迷惑メール判定を解消するため、DNSへのSPFレコード追加を推奨。
レコード種別：TXT
値：v=spf1 include:xserver.jp ~all
2.フェーズ別進捗
フェーズ1（必須・リリース前）
| 項目 | 状態 |
| パスワードのハッシュ化（bcrypt） | ✅ 完了（実装済み確認） |
| HTTPS強制 | ✅ 完了 |
| セッションのセキュア設定 | ✅ 完了 |
| ログイン失敗のロック機構 | ✅ 完了（実装済み確認） |
フェーズ2（リリース後早めに）
| 項目 | 状態 |
| セキュリティヘッダー（HSTS等） | ✅ 完了 |
| 不審ログイン通知メール | ✅ 完了 |
| SPF・DKIMの設定 | ⬜ 未対応（推奨） |
| パスワードリセットフローの強化 | ⬜ 未対応（次回 |
建設アシストセキュリティ監査
1. セキュリティ監査の実施
iso_app （建設アシスト）のセキュリティ強化を実施する
1.1 監査方法
Claude Code(Opus 4.7)を「セキュリティ監査員」として起用し、以下の観点でアプリケーション全体を調査しました。
- 認証・認可の漏れ(全コントローラーを網羅的に調査)
- テナント分離の実装状況(マルチカンパニー対応の確認)
- ファイルアクセス制御
- AI API への機密情報送信リスク
- 入力検証・出力エスケープ
- 依存ライブラリの脆弱性
1.2 監査サマリー
| 重大度 | 件数 | 対応状況 |
| Critical | 6件 | 4件完了・2件対応中 |
| High | 8件 | 7件完了・1件対応中 |
| Medium | 2件 | 計画中 |
| 合計 | 16件 | 11件完了 |
3. High 項目の詳細
| 項目 | コントローラー | 内容 | 状態 |
| 認可漏れ | ChecklistController | getEvidence で他社データをJSON取得可能 | ✅ 完了 |
| 認可漏れ | EnvironmentController | index/edit/save/aiEstimate でテナント確認なし | ✅ 完了 |
| 認可漏れ | RiskAssessmentController | downloadAttachment で他社ファイルダウンロード可能(16メソッド) | ✅ 完了 |
| AI情報 | AuditAiService | 被監査対象名・業務概要がAPI送信される | ⚠ 対応中 |
| AI情報 | SafetyPatrolController | 作業内容・使用機械の詳細が送信される | ⚠ 対応中 |
| AI情報 | risk_assessment.blade.php | 下請業者名・プロジェクト名がプロンプトに含まれる | ⚠ 対応中 |
4. 是正処置の内容
4.1 共通トレイトの新規作成
認可ロジックを一元化する AuthorizesTenantAccess トレイトを作成しました。
app/Http/Controllers/Concerns/AuthorizesTenantAccess.php
このトレイトにより:
- 認可ロジックが1箇所で管理される
- 各コントローラーへの適用が use 一行で済む
- 将来の Policy 移行への布石となる
- 役割ベースの例外(システム管理者は全社アクセス可)を正しく処理
4.2 適用したコントローラーと保護されたメソッド数
| コントローラー | 保護メソッド数 | 対応回 |
| ProjectController | 8メソッド | 第1回 |
| ConstructionPlanController | 15メソッド | 第1回 |
| SafetyPatrolController | 14メソッド | 第1回 |
| ChecklistController | 6メソッド | 第1回 |
| EnvironmentController | 4メソッド | 第2回 |
| RiskAssessmentController | 16メソッド | 第2回 |
| 合計 | 63メソッド | ー |
4.3 テストケース(26件 全PASS)
各コントローラーに対して以下のパターンを網羅的にテスト:
- 他社ユーザーが各リソースにアクセス → 403
- 自社ユーザーがアクセス → 200(正常)
- role=1 システム管理者 → 全社アクセス可(200)
- 削除・変更系でDBの状態が変わらないことを確認
4.4 実施コストと効果
| 項目 | 内容 |
| 実施時間(合計) | 約2時間半 |
| API利用コスト | $6.51(約1030円) |
| 外注した場合の市場価格 | 130〜350万円相当 |
| コスト比 | 約1300〜3500倍の費用対効果 |
| コード変更量 | 673行追加、12行削除 |
| テスト件数 | 26件 全PASS |
2. Critical 項目の詳細
2.1 テナント分離の欠落(Critical 1〜4) ✅ 完了
最も重大な問題でした。URL のIDを変えるだけで他社のデータに読み取り・編集・削除アクセスが可能な状態でした
| 対象コントローラー | 影響範囲 | 重大度 |
| ProjectController | show/edit/update/destroy/editOverview/updateOverview/uploadPhoto(8メソッド) | Critical |
| ConstructionPlanController | downloadDocx/downloadXlsx/generatePdf/diagramEditor等(15メソッド) | Critical |
| SafetyPatrolController | create/store/index/show/destroy/generateAiChecklist等(14メソッド) | Critical |
| ChecklistController | deleteEvidence/getEvidence等(6メソッド) | Critical |
2.2 AI API への機密情報送信(Critical 5〜6) ⚠ 対応中
発注者名・予算・下請業者名・近隣企業名などが、マスキングなしで Anthropic Claude API に送信される可能性がありました。
【現状の評価(設計意図の確認後)】
現状のAI利用は「チェックボックス選択による固定語彙のみを送信」という設計になっており、実質的な機密情報漏洩リスクは低い状態です。ただし、将来の機能拡張で誰かがフリーテキストを送る実装をしてしまうリスクの予防として、コードレベルのガード機構を実装予定です。
5. 進捗状況
| フェーズ | 内容 | 状態 |
| Phase A | リスクアセスメント(自主監査) | ✅ 完了 |
| Phase B-1 | Critical 1〜4 テナント分離 | ✅ 完了 |
| Phase B-2 | High 7〜9 認可漏れ(Environment, RiskAssessment) | ✅ 完了 |
| Phase B-3 | Critical 5〜6, High 10〜12 AI関連 | ⏳ 次フェーズ |
| Phase B-4 | Medium 13 ファイル名処理 | ⏳ 後ほど |
| Phase C | AIゲートウェイ構築・匿名化 | 📅 来月 |
| Phase D | 監視・運用体制の確立 | 📅 数ヶ月後 |
| Phase E | 継続的改善(PDCA) | 継続 |
6. 次フェーズの計画
6.1 AI送信情報のガード機構(InputValidator)
現在の「固定語彙のみ送信」という設計意図をコードで強制するバリデータークラスを実装します。
- 会社名・個人名らしき文字列の検出
- 長い数字列(電話番号・契約番号等)の検出
- 検出時の警告ログ記録
- 既存のAI Serviceへの組み込み(5箇所)
6.2 将来計画:ローカル AI 前処理
契約事項・技術的背景・経営内容の文書化を扱う際、自前サーバーに置いたローカルAIで一般化処理をしてから外部AIに送信する仕組みを構築予定です。
- ルールベース匿名化サービス(Phase 1): 氏名・会社名・金額の自動マスキング
- ローカルLLM検証(Phase 2): Ollama + Llama 3.2 などで自前AIの感触をつかむ
- 統合AIゲートウェイ(Phase 3): 匿名化→外部AI→復元のパイプライン構築
日曜日も天気が良い
建設アシストのコードが多くなってきたので、Claude Codeのトークン消費が多くなってくる（毎回、コードを読み込んで応答するため）・・・2日ごとにクレジット要求が来るようになったので、今噂のchatJPのClaude Code向けのプラグインであるCodexをインストールをして、さっそく工事管理のフロントエンドを修正させたが、ずいぶん時間がかかり、おまけにClaude codeも消費しているようで、またクレジットが切れてしまった・・・いくら請求が来るのか戦々恐々・・・Codexが使えるようであればFreeから契約するかと思っていたが、もう少し様子をみる必要がある・・・・Claude Codeを使わなくても、Clude,Geminiなどでもコード作成はできるが、スピードとシステム全体の網羅性はClaude Codeを使いだすと数倍以上に効率が良いため、中々戻れない
天気が良い日が続く
内部監査システムを構築
昨日に引き続き内部監査のシステムを構築する・・・ようやく、難しい監査チェックシートを作成、かなりClaudeを使い倒していると、昨日に引き続きもう追加のクレジットの要求・・・かなりの金食い虫だが、仕事は素晴らしいので対価としては多少納得
内部監査システムはかなり完成に近い、明日で細かな詳細を仕上げるかな
内部監査の複雑な仕組みのアプリうケーションが作成できれば、どのような業務アプリも作成できる自信がついた
雨の4月の最終日
4月の最終日は、朝から雨となり一日中降り続く・・・ゆっくりと朝食をした後に、レインコートを着込んでキクの散歩・・いつもより短いコースで切上げる
今日は、ネットワーク工程表のアプリを仕上げることに・・・しかし、最近のClaudeは少しポンコツ気味なってきた、要求が難しいのもあるが、中々良い結果を返さない・・・何回も繰り返していると、トークンが増えて、またクレジットを要求される・・・今回はかなりつぎ込んだな
雨の日曜日
朝から少しづつ降り出した雨は、昼頃から本降りの雨となって夜半まで降り続く・・・朝は、キクと元宇品の森を散歩で歩く、日曜日なのでマラソンする人や、犬の散歩など多くの人が来ていて、灯台の駐車場は満車の状態・・・散歩の帰りには、ガソリンが警告灯が付いたので、四国の旅行で給油したときから給油していない・・忘れないうちにスタンドで給油、まだガソリンは￥157と安かった
昼前に買い物に行き、明日の厨房の大工仕事のため、木材を購入する
昼からは、ネットワーク工程表のアプリケーションを作成する・・・やはりネットワーク工程表は中々難しいが、Claudeが手助けしてくれるが、難しい依頼はトークンの消費が激しく、クレジットの要求がすぐ来るので、使い方は考えながらする必要がある
夕方には、ほぼ納得できるような工程表が作れるアプリケーションが出来上がった・・・実際に入り色な工程を作成して調整してゆく必要があるが、問題は印刷のスケールをどのように調整するかが当面の課題、ネットワークがうまく表現できない
建設アシスト Help作成
きょうから少し天気は下り坂
建設アシストも予定していたメニューは、ほぼ出来上がったので、各ページにHelpのモーダルをつくり、使い方などの説明を書いてゆく
それに合わせて、動きやメニューボタンの配置など細かな操作部分の改修を行ってゆく・・・地味な作業だが、これが重要・・・・しかし、割と単調なので疲れてしまう
AIの選定の調整も重要なので、条件を変えて確認する
小雨の桜は八分咲き
昨日にようやくClaude Codeに渡す要件ができたので、改めてもう一要件を見直して、修正する
昼過ぎからClaude Codeに要件を渡すと、修正を含めて2時間ほどで、環境側面のアプリケーションが作成できた・・・Claude Codeは素晴らしく優秀、しかし昨日に月の利用限度は超えてしまい、追加のクレジットを購入することになった
さてこれから、色々データを与えて正しい判断をするかを確認しなくてはならない
4月は雨から
早くも4月となった
朝から雨が降っている、キクの散歩はみなと公園をぐるりと回る・・桜が咲き始めた
いよいよ、建設アシストの環境側面をつくるが、中々難しい・・・まずはもう一度、ISO14001を読み直し、環境側面とは何か設定しなおす・・・ようやく、頭が整理できたので。AIで要件をつくる
昼からディスプレイの配置換え
午前中は散歩から帰ると、建設アシストのリスクアセスメント作成手順のデザイン変更とAIによるRA項目の特定を調整する・・・かなり使えるようになってきた
彼岸の中日は墓参り
良い天気なので、前の日に花を購入して墓参りにRIEと行く、中日なので墓参りの人が多くて混雑していた・・そのあと、買い物に、かなり多くのものを購入
