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 | 解説画像 |
Custom_regulations （現場固有のその他規制）
regulations とほぼ同列構成project_id+is_checked
is_checked が直接カラムにあり、checklist_results とは別管理
2．現在の処理フロー
“`
[工事管理ページ]
│
▼ 法規制編集ボタン
[edit_Laws_Regulations.blade.php]（編集画面）
│
├─ ✨AI法規制判定ボタン（タブ単位）
│ │
│ ▼ POST /projects/{id}/ai_recommend（Ajax）
│ AiRecommendationService::recommend()
│ – regulations 全件取得
│ – project->overview（工事概要テキスト）を入力
│ – Claude API に問い合わせ → ID配列を返却
│ – session(‘ai_suggestions’) に保存
│ – ページリロード → チェック状態に反映
│
├─ 手動チェック（親・子チェックボックス）
│
└─ 登録/更新ボタン → POST /projects/{id}/checklist/save
– checklist_results を全削除 → 再挿入
– custom_regulations の is_checked を更新
[index.blade.php]（閲覧画面）
– checklist_results に is_checked=true のもののみ表示
– session(‘ai_suggestions’) があれば合体してハイライト
4-2. 第一段階：条件選択による法規制特定（モーダル☑ボックス）
モーダルのチェックボックスの項：”D:\Dropbox\03システムアシスト\00-Bulid-Assist\法規制の見直し\20260605法規制検索モーダル項目.xlsx”
この項目をモーダルで纏める
・検索条件は上記に示す
4-3. 第二段階：AIによる残留判定（複雑条件のみ）
検討したが良いAI判定の条件が絞れないので、今回は考慮しない・・・次のステップで
4-4. タブメニューの移動
現在nav_extraスロット（ヘッダー内）に注入しているタブを、コンテンツエリア上部に移動。
【現在】
ヘッダー行：[工事管理] [基本届出] [選択届出][元請責務] [元請確認] [環境関連] [その他規制]
【変更後】
ヘッダー行：[工事管理]
─────────────────────────────────
操作バー：[条件で特定] [印刷/PDF] [法規制表示] [登録/更新] | 改訂日: xxxx
─────────────────────────────────
タブ行： [選任・設置・届出] [元請責務] [元請確認] ・・・・
─────────────────────※タブメニューの名称はselect_modeに従ってください
コンテンツエリア────────────
@section(extra_tabs)の仕組みを廃止し、blade 内でタブを直接描画します。
共通化
| 項目 | 現状 | 改善案 |
|---|---|---|
| タブ描画 | index と edit に同じコードが重複 | @include(‘Laws_Regulations._tab_bar）等のパーシャル化 |
| 法規制行の表示 | 親・子の表示コードが両画面で重複 | @include(‘Laws_Regulations._regulation_row |
| 条件モーダル | 新規 | components/laws_condition_modal.blade.phpとして独立コンポーネント化 |
| キーワードマッチ処理 | 新規 | App\Services\RegulationMatcherServiceとして Service 層に集約 |
３．現在の問題点
| # | 問題 | 影響 |
|---|---|---|
| 1 | AI判定の入力が project->overview（自由記述テキスト）のみ | AI精度が工事概要の書き方に大きく依存 |
| 2 | ai_descriptionに制御フラグ（【選択必須】）を埋め込み | 検索/条件判定とフラグが分離できていない |
| 3 | 「全件DELETE→INSERT」の洗い替え保存 | 複数ブラウザ同時操作や途中エラー時にデータ消失リスク |
| 4 | タブメニューがヘッダーの nav_extraスロットに注入 | レイアウト上の柔軟性が低い |
| 5 | AI判定がセッションベース（ai_suggestions） | ページ遷移・ログアウトで消える、DB永続化されない |
| 6 | インライン onclick=””が混在（index.blade.php） | CSPの unsafe-inline削除方針と矛盾 |
4.見直し方針と提案
4-1. CSVデータ構成の見直し（regulations テーブル）
Excelの法規制データを見直した：”D:\Dropbox\03システムアシスト\00-Bulid-Assist\法規制の見直し\20260605-法規制リストｰ最終.xlsx”
・このデータをCSVとする
・検索方法について、
select_modeには、選択させるか否かの条件を決めている
・必須：どの条件でも必ず選択する項目
・選択：キーワードによって選択するフラグ（select_OR、select_ANDに関係）
・保留：あまり重要ではなく、事例が少ないもの、当面、選択しない
・AI：キーワードでは選択できず、複数の条件からAIが判定するもの（ai_keywordsを参考）・・・当面AIは考えない（次のステップ、保留扱い）
・select_ORには、法規制を特定するときのキーワードを記載している
・キーワードは、選択条件のモーダルで決定する
・ここに改行された、キーワードはすべてORの条件となる
・select_ANDには、法規制を特定するときのキーワードを記載している
・キーワードは、選択条件のモーダルで決定する
・キーワードは、前のselect_ORとANDの条件となる
・ai_keywordsは、select_modeでAI判定とされたとき、参考にする文章を記載する
・full_law_textは、法規制の本文を記載している
・法規制の全文表示モーダルで使用
5.セキュリティ・共通化の提案
セキュリティ
| 項目 | 現状 | 改善案 |
|---|---|---|
| テナント分離 | index と edit に同じコードが重複 | @include(‘Laws_Regulations._tab_bar）等のパーシャル化 |
| 洗い替え保存 | 全DELETE→INSERT（危険） | upsert()またはupdateOrCreate()に変更し、ソフトデリートを検討 |
| AI入力 | overviewテキストをそのまま渡す | 条件値の構造化データに変更することでプロンプトインジェクション耐性が向上 |
| インライン onclick | index.blade.phpに混在 | addEventListener` に統一（CLAUDE.md方針に準拠） |
| エビデンスファイル | evidence/{filename}でpublic保存 | テナントIDをパスに含める（他プロジェクトのURLを推測されるリスク） |
6.実装ステップの提案（優先順）
| Step | 内容 |
|---|---|
| Step 1 | regulations テーブルにカラム追加（condition_keywords, always_apply, never_apply）＋CSVデータの整備 |
| Step 2 | 条件選択モーダルの作成＋RegulationMatcherService の実装＋edit画面の「AIボタン」を「条件で絞り込む」ボタンに変更 |
| Step 3 | タブをヘッダーから切り離してコンテンツ内に移動＋edit/index 共通パーシャル化 |
| Step 4 | 洗い替え保存 → upsert 方式に変更 |
| Step 5 | 第二段階 AI判定（条件マッチ後の残留分のみ）＋AI入力を構造化条件データに変更 | |