投稿者: たんご・あるふぁ・まいく
北浦漁港へ
日向市に出張
たっぷりある時間の中で、Claudeと肥大になった施工計画の作成画面について分析を実施してもらう・・・サーバからコードをダウンロードして、iPadなどでちょっとやりにくいが、Claudに読ませる・・色々と改善案を提案して、三つの改善指示書を作成してくれる・・・特急にちりんは、もうすぐ延岡に、外はいつの間にか雨となっている

宮崎までの日豊本線は長い、大分からは単線で延岡までは、曲がりくねった山の中をのんびりと走る
特急日輪は、宮崎空港まで直通の貴重な列車・・ほとんどは大分で乗換



宇品みなと公園

施工計画書の表紙と目次の編集機能の整理
計画書のヘッダーとフッターの編集機能、また表示がおかしいことの修正,、余白の調整・・まだまだ、改善すべきところは多い
しかし、最近どうもClaude Codeの切れが悪い・・・コードが肥大化したかな、整理を考える必要がある

J58を修理工場に
今週は天気が悪くなるとのことだが、良い天気の月曜日、朝は久しぶりに元宇品の森を歩く・・・最近は、森のアップダウンの散歩は辛くなってきている、午前中は今週の仕事の段取りをして、昼からはキクを助手席に乗せてJ58を修理工場に移送
最近は旧車を修理してくれる修理工場が無い、昔の車の修理はわからないそうだ・・・いつもの修理工場に無理を言ってお願いする、パーツがあればとのことなので、パーツリストからパーツを頼むが、あっているか少し不安、パーツも中々高価で、失敗すると痛手が大きい、修理の期限は付けないが7月中には終わらせてもらいたい


施工計画書の再構築 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.現状調査結果
1-1.ファイル構成と役割
| resources/views/construction_plans/index.blade.php | 大項目一覧(1〜24番 + 表紙・目次)のチェック管理画面 |
| resources/views/construction_plans/print_item.blade.php | 個別項目のPDF印刷用ビュー(キャッシュ無効化・A4最適化) |
| resources/views/construction_plans/ai_print_item.blade.php | AI整形HTMLの編集・出力画面(Word/Excel生成機能付き) |
| resources/views/construction_plans/diagram_editor.blade.php | フローチャート・図面エディタ(A4キャンバス・テンプレート機能) |
| app/Http/Controllers/ConstructionPlanController.php | メインコントローラー(1,550行・39メソッド) |
| app/Models/ConstructionPlan.php | 施工計画書モデル(プロジェクトと1:1) |
| app/Models/ConstructionPlanItem.php | 大項目モデル(TipTap JSON対応) |
| app/Models/ConstructionPlanImage.php | 画像管理モデル |
| app/Models/ConstructionPlanTemplate.php | テンプレートモデル(会社別/共通) |
コントローラーに editItem() メソッドと editPlan() メソッドがあり、それぞれ
construction_plans.edit_item と construction_plans.edit_plan を参照しているが、ファイルが存在しない。
これはルーティングエラーの原因となる可能性がある。
調査時点では該当ルートが routes/web.php に登録されているかは要確認。
墓参り 工事管理の見直し

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 統合版に書き換え |
J58のフロント ナックル カバー
三菱ジープJ58の車検が近づいてきたが、フロントのナックルカバーが破れている
これでは車検に通らないので、修理を依頼するが部品があればとのことなので、パーツリストから探して3点の左右を注文する・・・しかし、いつもの車検屋さんでは修理はできないという(やったことが無い)

MB002241

MJ908005

MJ908005
元宇品散歩 建設アシスト安パト見直し

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
法規制のコードを見直しを始めた・・・まずは現状分析
1.現在のテーブル構成
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”のような属性+委譲リスナーに寄せれば機械的に直せる
元宇品の散歩
建設アシストのコードのセキュリティ対策として、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 標準モーダル(フォーカストラップ付き) |
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 の定期実行 | 低 |
海の見えるレストラン
新しいマザーボードに交換
現在のパソコンの構成
- マザー 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
- M.2 SSD PCIe Gen4x4 NVMe M.2 diloca EN760 2TB 2280 4800MB/s
- 電源 MSI 750W MAG A750GL PCIE5 PS1326
・PCIe 5.0 GPU ネイティブ16ピン(12VHPWR)450W対応
・ATX 3.0 対応/フルモジュラー設計
・80 PLUS Gold認証取得 - ケース NZXT(CA-H510E-B1)


ログインに関するセキュリティ
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の設定 | ⬜ 未対応(推奨) |
| パスワードリセットフローの強化 | ⬜ 未対応(次回 |












































