カテゴリー: Walk
五日市埋立で散歩


4.結果
- mainマージ+本番デプロイ3回、すべて成功・稼働確認済み(最終コミット bd1cf1b)
- 自動テスト: 106件(うち5件失敗)→ 119件全パス(テスト14件新規追加・失敗0)
- 外形確認済み: セキュリティヘッダー出力・CookieのSecure属性・自己登録の閉鎖・診断ページの撤去
- 2026-07-11再検証の指摘は完了。システムは「Critical/High/Medium指摘ゼロ・依存脆弱性ゼロ(リスク受容2件は記録済み)」の状態
5.残課題(急ぎでない・別フェーズ)
- H-3: CSPのunsafe-inline除去(インラインJSの外部化 or nonce方式・大きめの作業)
- L-3: 同時編集ロックの精度向上(lock_version整数化)
- vite 4→8 メジャー更新(開発サーバー限定の脆弱性解消)
- x-data-spreadsheet(表エディタ)の代替検討 — XSS修正版が存在しないため。現状は同一会社内の編集権限者に限られるためリスク受容中
- 動作中の旧式遷移ボタン6箇所の data-href 方式への移行(1と同時に実施が効率的)
セキュリティ再検証・是正作業 全体総括
1.目的
システム全体を改めて検査(再検証)し、見つかった弱点を重要度順にすべて是正して本番に反映する
2.計画
4つの観点(認証・テナント分離・インジェクション対策・設定/依存関係)で並列監査を実施し、指摘を重要度別に整理 → Critical 0件・High 4件・Medium 9件・Low 9件・依存脆弱性多数・・・中核部分(認証・会社間のデータ分離・SQL/XSS対策)は基準適合と評価
| 区分 | 内容 |
|---|---|
| バッチ1 | 緊急度の高いもの:テンプレート操作の権限制限・AI生成HTMLのXSS対策・不要ファイル削除 |
| バッチ2 | 入力データの保存範囲固定・Cookie保護の既定化・セキュリティヘッダー補強・古いテストの整理 |
| バッチ3 | 依存パッケージの脆弱性解消・細かな改善9件(L-1〜L-9) |
| 確認事項5件 | 確認事項5件 |
3.実施
バッチ2
- 現場情報の保存を「検証済みの項目だけ」に固定 — 従来は細工したデータ送信で現場の所属会社を書き換えられる余地があった(調査中に登録処理側にも同じ問題を発見し、両方修正)
- セッションCookieのSecure属性を既定でON — 設定漏れがあっても自動的に安全側になる
- セキュリティヘッダー補強 — カメラ・マイク等のブラウザ機能無効化、クリックジャッキング・フォーム送信先の制限
- 実態と合わなくなっていた古いテスト5件を「現仕様の回帰検知」に書き換え
バッチ3
- 依存パッケージの脆弱性: composer 26件 → 0件(Excel処理ライブラリの重大な脆弱性含む)、npm 18件 → 4件(残りは開発環境限定等で影響なし・記録済み)
- パスワード変更・リセット時に他の端末のログインを即時無効化(乗っ取り後の締め出し対策)
- ファイル保存名のランダム化、デバッグ出力の削除、旧Gemini設定の廃止 ほか
確認事項
- 変更履歴(UserChangeLog): 会社間分離の仕組みを適用(設計どおり)
- 本番設定: 現地確認の結果、実は問題なし(APP_ENVは行なしでも本番扱い・GEMINIキーも本番には無かった)
- プロキシ設定: 診断ページを一時設置しTAMの実測で「前段プロキシなし」と確定 → IP偽装を許す設定を撤去
- 過去のAI生成データ: 一括洗浄コマンドを作成 → 本番で確認した結果、対象0件(すべて安全なデータのみ)
- 旧GeminiAPIキー: TAMがGoogle側で失効済み
元宇品の森を歩く ユーザー管理の検証
ユーザー管理検証
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
葡萄が実っている 工程表を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件パス維持 |
大河を散歩

甲斐犬のキクとの散歩は、旭町から西霞町に、ここから西本浦町に登り、団地を抜けて北大河から大河に下り、再び旭町に出て帰る・・何となく歩いていたら9000歩にもなった・・・甲斐犬のキクは最後は暑さでバテバテの様子(途中で2回水を飲ませたが)
今日は寝起きから喉が少し痛い・・・風邪かな、帰ってからは、なんとなく疲れたのか机でウトウト、何もせずに夕方になった
なんとなく湿気で体がべとべと、夕食前に入浴してすっきりした
雨のみなと公園
五日市の埋立地 施工計画エディタ画面修正
宇品みなと公園

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

京橋川の土手を散歩 施工計画書再構築
施工計画書 セットアップ画面 再構築
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 に登録されているかは要確認。
雨の宇品波止場公園 メモリの売却
雨の竜王公園を散歩 アップロード画像の縮小
朝から雨が降り続ける日曜日、娘たちを送って、また迎えに行く・・・今日はお隣が地鎮祭
建設にアップする画像の軽量化のルーチンを組み込んで、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のみ)
キクと散歩 法規制コードの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条:足場・型枠支保工等の設備面の措置
MACmini4にLaravelローカル環境構築
パソコンのエラー
日曜日も天気が良い


建設アシストのコードが多くなってきたので、Claude Codeのトークン消費が多くなってくる(毎回、コードを読み込んで応答するため)・・・2日ごとにクレジット要求が来るようになったので、今噂のchatJPのClaude Code向けのプラグインであるCodexをインストールをして、さっそく工事管理のフロントエンドを修正させたが、ずいぶん時間がかかり、おまけにClaude codeも消費しているようで、またクレジットが切れてしまった・・・いくら請求が来るのか戦々恐々・・・Codexが使えるようであればFreeから契約するかと思っていたが、もう少し様子をみる必要がある・・・・Claude Codeを使わなくても、Clude,Geminiなどでもコード作成はできるが、スピードとシステム全体の網羅性はClaude Codeを使いだすと数倍以上に効率が良いため、中々戻れない
















































































