横川で仕事

朝は少し小雨が降っていたが、市電に乗って横川駅まで。今日はここで仕事となる・・・少し早く着きすぎたので、駅前のパン屋でモーニングを注文して少し時間をつぶす
現場でないので、仕事は速く終わる・・・横川のSDKさんの会社に、久しぶりに寄って、SDKさんとXさんを交えて、久しぶりに無駄話をして、また市電に揺られて帰途に

皆実町6丁目から市電で横川駅に(時間にして45分程度・・・終点までは長い)
昼食のお弁当はむさしのおにぎり弁当

キクと元宇品

朝は甲斐犬のキクと元宇品をぐるりと回る

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、変更なし、コメントを追記

▶この続きを見る・・・・

五日市の埋立地 施工計画エディタ画面修正

今日は雨は上がった 五日市の埋立地
大きな砂州が伸びていた 朝食と昼食を兼ねてフレンチトーストとケンタッキーのフライドチキン

Claudeで質問し検討し、指示書を作成させて、Claude Codeで作業をさせるパターンで、テキストボックスの修正をする・・Claude Codeだけでは実行するだけがメインなので、検討が不足する・・やれやれ、恐ろしい世界になったものだ

一日かけて、エディタのテキストボックスの編集を修正
ようやくテキストボックスのウインドウ画面のデザインが確定

J58のパーツが届く 施工計画の全面修正

土曜日だが、朝から一日雨がℎぐり続く・・・まあ、梅雨だから当たり前だが、キクの散歩はみなと公園・・・一日中、施工計画の改修

フロントブレーキのシリンダー4個を購入
フリーハブのパッキンとキングピンのシムを購入

施工計画書作成のエディタ分析(diagram-editor-script)

  • 完全自作図面エディタエンジン
  • 174関数 / 3,686行 / 166KB、→ 単一ファイルとしては限界に近いサイズ
  • 外部ライブラリなし、SVGとdivだけでDrawio・Visioのような図形編集を自力実装
観点評価
コード品質セクション分けが明確で追いやすい
機能完成度商用ツールに近いレベル
CSP対応95%完了・ページタブのみ残存
データ設計JSON構造が明確で拡張しやすい
リスク箇所renderPageTabs()のinline onclick


リファクタリングの優先順位

優先内容効果
🔴 高 getTargetId()関数を1つ作りID取得を統一バグ防止
🔴 高 setBg()をapplyBoxBg()に統合重複解消
🔴 高 toggleBorder()をapplyNodeBorderToggle()に統合重複解消
🟡 中 ctx系をコア関数に引数追加で統合コード削減
🟡 中 tbl系を別ファイルに切り出し見通し改善
🟢 低 snapshot()をラップして自動呼び出し化snapshot()をラップして自動呼び出し化呼び忘れ防止
▶この続きを見る・・・・

渡川ダムに 夜遅く広島に帰る

日向からR327で椎葉方面に、道の駅とうごうからR446に、途中に若山牧水の生家があり、しばらく行くと西の正倉院と言われる百済の里がある鬼神野から山を越えて渡川に

道の駅鬼神野 誰もいない
日向市駅でかなり待つ

夕方には仕事も終わり、雨の中、日向市から特急で乗換て小倉まで4時間ちょっと、小倉から新幹線に乗ったが、関門トンネルを過ぎて厚狭駅で、止まったままで動かない・・浜松での人身事故の影響らしい、倍以上の時間がかかり、広島まで2時間かかる・・・疲れた

渡川ダムに流れ込む渡川 雨が降っている
日向市駅から特急で大分で乗換て小倉まで4時間
小倉では、またワンピースの青いこだまが走っている

日向市に出張

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

広島を7:26の新幹線で小倉に、ここから特急にちりん、宮崎空港行きで4時間12:38に日向市に到着

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

別府駅を通過、うみたまごの看板 うみたまごはヒデがお父さんと一緒に行って喜んでいた・・・別府で購入した「毎日が地獄です」と言うTシャツを着て。少し照れていたような顔を思い出す
臼杵から山に入りかなり低速、延岡まで 雨が降り始める
日向市駅

宇品みなと公園

宇品みなと公園を散歩 フェリーが出港

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

J58を修理工場に

天気が良いので、久しぶりに元宇品の森を歩く

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

J58に甲斐犬のキクを乗せて、ドライブ
フロントアクスルブーツ交換に修理工場へ
▶この続きを見る・・・・

施工計画書の再構築 Claude Fable 5の話

今週はほとんどの時間を施工計画書の再構築で費やした・・・自由に表や画像およびテキストをキャンバスに配置して、計画書をつくることは難しい・・・結局、色々試したが、使い慣れたVisio的な画面操作で作成することにした・・・作成はやはり、かなり難易度が高く、構築指示も何回も失敗したが、さすがにClaude Code、最後は何とか意図する内容にまとめてくれた
これから、実際に施工計画書を作成して、効果的なテンプレートをつくりながら、システムの使い勝手を検証してゆく

施工計画書 セットアップ画面 あらゆるタイプの施工計画書に対応できる

世界中のあらゆるサーバーはハッキング出来ると恐れられ、提供が中止されていたClaude Mythosに、安全フィルターが施されたClaude Fable 5が提供させるようになった・・・6/22まではトークンは消費(2倍)されるが、無料で使うことができるようになっていた・・・この間にシステム全体の診断をさせようと思っていたら、開始から3日目でUSAからの指示で提供が禁止(アメリカ国民以外は使用禁止・・だが、区別ができないので全世界で禁止となった)されてしまった・・・これからのAIの使い方に新しい波がやってくる予感

施工計画書 作成画面(Visio的な操作を実施)
▶この続きを見る・・・・

京橋川の土手を散歩 施工計画書再構築

京橋川の土手を散歩
甲斐犬のキクと一緒に

施工計画書 セットアップ画面 再構築
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-typeproject_plans.change_work_type工事種別変更
POST{plan}/sectionsproject_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.phpAI整形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.phpprojects.overview.edit / projects.overview.update ルートを削除
ProjectControllereditOverview() / 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.phpL105, L109, L113, L117onchange=”updateRowColor(…); autoSave()”
create.blade.phpL82onclick=”runAiProcess(…)”
index.blade.phpL43, L47, L51, L103, L115onclick=”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に取り込む画像の軽量化を図る

建設アシストの最初の画面を組織全体の管理画面として、組織urlをインフレームにしていたが、ほとんどエラーとなるので、画像に切り替え

画像アップロード共通化・圧縮対応

1.概要

システム全体の画像アップロード処理を共通サービス化し、GDライブラリによる圧縮・リサイズを追加した

2.対象箇所の調査結果

コントローラーメソッド最大  ストレージパス
CompanyAdminControlleruploadLogo5MBcompany_logos/
ProjectControlleruploadPhoto50MBphotos/
ChecklistControlleruploadEvidence50MBevidence/
ConstructionPlanControlleruploadItemImage5MBplans/{id}/images/
ConstructionPlanControlleruploadTemplateImage5MBtemplates/images/
SafetyPatrolControllerstorePhoto10MBpatrol_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シートをもう一度、見直しと再構築をして、いよいよコードを作成する

もう一度、法規制をまとめた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_idFK現場
regulation_idFK法規制
is_checkedboolean適用/非適用

c

法規制のコードを見直しを始めた・・・まずは現状分析

1.現在のテーブル構成

regulations`(法規制マスタ)

※課題:ai_description1列に「キーワード」と「制御フラグ」を混在させている

カラム役割
idPK
parent_idFK(self)親=null、子=親ID(2段構造)
group_codestring法律名(主に親)
ref_lawstring関係条文(主に子)
action_contentext実施すべき内容
full_law_texttext原文(展開表示用)
ai_descriptiontextAI判定用キーワード(【選択必須】/【選択しない】制御フラグも兼用)
explanation_imagestring解説画像
▶この続きを見る・・・・

我が家の妻側が丸見え 労働安全衛生法のレビュー

隣の家の解体が終わり、家の妻側が丸見えに
長い間、外壁も手入れをしていないので少しくたびれています
夕方にキクと散歩

建設アシストの法規制管理の見直しを貸しする・・これで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 の定期実行