タグ: 甲斐犬のキク
QMACサイトの再編とWordPress化

4. 構築過程で発見・対処した問題
8件すべて、実際に動かして判明した内容
- .htpasswd が公開ルート直下に置かれ、.htaccess は全行コメントアウト(旧サイトの重大な設定不備)
- 管理画面でカスタムフィールドが編集できない(supports に custom-fields 欠落)
- 中身のない年度18本もリンク表示され、空ページへ飛ぶ状態
- 年度アーカイブが機能せず、ブログ形式・投稿日で表示
- 一括投入で画像圧縮が効かない経路があり、原本1.71MBが残る
- 静的アーカイブが全ページ文字化け(HTTPヘッダのcharsetがmetaより優先)
- マニュアルの開催日入力手順が実際の画面と相違(手順どおりに操作すると失敗する)
- 空の画像ブロック20個がすべて検証エラー
5. 旧サイト由来の誤記(原本どおり投入・訂正待ち)
| 行事名が空 | 2件 | 旧サイトが行事名自体をPDFリンクにしていた |
| 日付の年が1年ずれ | 3件 | 2008年度、曜日は正しく年だけ誤り |
| 曜日が合わない | 4件 | 2020〜2023年度 |
| 表記の重複誤記 | 3件 | 「先進企業視察会視察会」 |
| 名簿の疑わしい記載 | 6件 | 「幹事→監事」「㈱ダイクレ㈱」等 |
6. 事務局向けマニュアル
780行・9章+付録2
対象を事務局に絞り、管理者向けの内容とは分けた・・・マニュアルは公開サイト上の固定ページとして設置している・・・更新経路は「ページ上で直接編集」に一本化・・・ 変換スクリプトとページ編集の二経路があると、どちらかの修正が失われる・・・スクリプトは移行用の一度きりのものとして明記のうえ保管
1. 移行前の状態と課題
| 構成 | frameset ベースの静的HTML |
| 規模 | 773ファイル / 2.74GB |
| 制作 | Dreamweaverで約15年間 |
| スマホ対応 | なし |
2. 資産の棚卸し
破棄したもの
| 運営委員会PDF | 1,534本 / 206MB | パスワード運用ごと廃止 |
| 死蔵HTML | 654本 | トップから到達不能な滞留分 |
| 制作元データ(.mif / .pef) | 207MB | サイト運用に不要 |
移行したもの
| 行事 | 192件(2008〜2025年度・18年分) |
| 添付ファイル | 368件 / 84MB(写真138・PDF230) |
| 固定ページ | 8本(協会案内5・名簿2・マニュアル1) |
| 静的アーカイブ | 16本(1992〜2007年度) |
3. 設計の要点
3-1. データと見た目の分離
| 親テーマ | twentytwentyfive(WordPress公式) | 本体と同時に更新される基盤 |
| 子テーマ | qmac(新規作成) | 配色・レイアウト・動的ブロック |
| プラグイン | qmac-core(新規作成) | 投稿タイプ・分類・管理画面整理 |
3-2. ブロックテーマの子テーマ方式を採用
当初はクラシックテーマを検討したが撤回した・・・クラシックテーマはWordPress本体の更新に追従しにくく、ブロックエディタで書かれた投稿との整合が崩れやすい・・子テーマ方式なら親テーマが本体と一緒に更新され、独自の差分だけを自前で保守すればよい。保守性と自由度が両立する・・・・親テーマが公式テーマである点も重要で、コアチームが保守しており、第三者テーマのように開発停止で行き詰まるリスクが小さい
3-3. 事務局が壊せる箇所を構造的に減らした
「マニュアルに書いてあるから大丈夫」ではなく、そもそも触れないようにする方針
| 権限 | 編集者権限(外観・プラグイン・ツールに到達不可) |
| 左メニュー | 5項目に限定 |
| ブロック | 102種を非表示にし、17種のみ許可 |
| パターン | 挿入可能なパターンを0本に |
| テンプレート | 編集欄を非表示にしたうえ、保存自体を拒否 |
3-4. 年度アーカイブの自動化
現行運用で最も手間だった作業を自動化・・・開催日を入力するだけで、年度タームの作成・付与・サイドパネルへの反映がすべて自動で行われる・・事務局の手作業はゼロ・・・・年度末の切替も、状態を「予定 → 終了」に変えるボタン1つ(取り消し可)に集約
| 更新の担い手 | 事務局 |
| 行事の追加 | 管理画面で入力 |
| 年度末の切替 | ボタンで切り替え |
| 過去年度リンク | 完全自動 |
| 写真の掲載 | ドラッグで追加(自動圧縮) |
| スマホ対応 | あり |
元宇品の散歩
五日市の埋立を散歩
キクの散歩
システム言語の研究
AIで作成させるシステムでTypeScriptTypeScript、Next.js、Vercel、Supabaseが良いと聞いたので、AIに説明をしてもらった
| name | 役割 | Laravel版での相当物 |
|---|---|---|
| TypeScript | 言語(型付きJS) | PHP 8.3 |
| Next.js | フレームワーク(画面+API一体) | Laravel + Blade |
| Vercel | ホスティング(サーバーレス) | Xserver |
| Supabase | DB+認証+ストレージ | MariaDB + Breeze |
利点
- 1. 型がAIの間違いを機械的に潰す、AIは存在しないプロパティやメソッドを平気で書きます–TypeScriptならビルド時に落ちるので、実行して気づくのではなく書いた瞬間に分かる・・これがAI開発で一番効く要素です。
- 2. フロントとバックが1言語1リポジトリ、Blade + Alpine.js + PHPのように「JSとPHPの境界」がないので、Claude Codeに渡すコンテキストが一続きになります・・・4,300行のインラインJS外部化のような問題が構造的に発生しません
- 3. push即プレビューURL、ブランチごとに本番同等の検証環境が自動で立つ。SupabaseもDBブランチを作れるので、DB込みで検証できます。サーバー・ネットワークの知識がほぼ不要です
欠点
- Next.js 16のApp Router / React Server Componentsは、AIが古い書き方を出す、Pages Router時代のコードが学習データに大量に残っていて、use clientの付け方やデータ取得の作法を混ぜてきます。「AI向き」と言われる割に、ここだけは頻繁に手戻りが出ます。
- Supabaseのマルチテナント分離はRLS(Row Level Security)が生命線、今のBelongsToTenantグローバルスコープ +AuthorizesTenantAccessは、アプリ層でLaravelが守る構造・・Supabaseはクライアントから直接DBを叩けるので、RLSポリシーを1本書き忘れたテーブルは全テナント筒抜けになります・・・モデル分のポリシーをAIに書かせて、その正しさを検証する体制が新たに必要になる。しかもRLS環境はテストが書きにくい(テストユーザーのJWTをモックするか、service_roleでバイパスするかの判断が要る)。セキュリティ設計の厳しさを一番重視されている方には、ここは素直に減点材料です
- サーバーレスの実行時間制限、マスキング→Anthropic API→結果整形という監査支援モジュールの処理は、秒数がかさむと関数タイムアウトに当たります・・・Xserverの普通のPHPプロセスのほうが素直な領域です。
- 従量課金でドル建て、支出上限が設定しづらい、Xserverの固定費に慣れていると読みにくい。数社規模なら安いですが、予測可能性は下がります。
甲斐犬のキクと朝の散歩
甲斐犬のキクと散歩
甲斐犬のキク 叔父さんの墓参り
ガジュマル

| コード | 画面名 | ルート名 | 補足 |
|---|---|---|---|
| AUD-SUM | 指摘リスト(監査指摘 統合一覧) | audits.findings_summary | 集計部分をAUD-AGGへ分離、統合一覧のみに縮小 |
| AUD-CA | 是正処置報告(1指摘=1報告の編集) | audit_corrective_actions.edit | 同一会社なら誰でも記入可(一般ユーザー含む) |
| AUD-CA-LIST | 是正処置リスト(報告書単位) | audit_corrective_actions.index | 監査員向け。導線はAUD-CA経由のみ |
| AUD-CA-PLAN | 是正処置リスト(計画配下・全報告書横断) | audits.corrective_actions_list | 一般ユーザーにも開放 |
| AUD-CA-SELECT | 是正処置一覧・計画選択(一般ユーザー向け簡易版) | audits.corrective_actions_select | |
| IA-MODAL-S1〜S6 | AI支援モーダル(事実メモ〜生成結果) | AI支援モーダル(事実メモ〜生成結果) | AUD-FIND内 |

監査各ページの名前の統一
画面名称を統一
| コード | 画面名 | ルート名 | 補足 |
|---|---|---|---|
| AUD-LIST | 内部監査計画リスト | audits.index | 監査アクセス保持者限定(一般ユーザー不可) |
| AUD-PLAN | 内部監査計画書 | audits.show | ボタン配置統一 |
| AUD-HOME | 監査実施一覧 | audit_execution.index | |
| AUD-HOME-M1 | 新しい監査を始める(モーダル) | AUD-HOME内 | |
| AUD-RPT | 個別監査計画・報告書 | audit_reports.show | |
| AUD-SCH | 監査予定表 | audits.schedule | |
| AUD-SCH-M1 | 予定を追加(モーダル) | AUD-SCH内 | |
| AUD-SCH-M2 | 予定を編集(モーダル) | AUD-SCH内 | |
| AUD-FIND | 個別監査指摘 | audit_findings.edit | 監査アクセス保持者限定 |
| AUD-FIND-M1 | 指摘 編集(モーダル) | AUD-FIND内 | |
| AUD-AGG | 指摘集計(部署別集計+全合計) | audits.findings_aggregation | 旧AUD-SUMの前半部分を分離 |
元宇品を歩く
京橋川の土手を散歩
甲斐犬のキクと散歩
元宇品の森を散歩
甲斐犬のキクと散歩
ひろしまみなとマルシェに 内部監査支援システム開発
朝は元宇品に散歩に行き、帰りにひろしまみなとマルシェに寄ってみる・・・炎天下の下、出店している人たちには脱帽ものです・・やはりお客は少なく営業的には苦しい・・・よしろう農園でしばらく雑談して帰宅、シャワーを浴びたらもう昼食
帰って月下美人を見ると昨晩に咲いていた・・残念見ることができなかった

内部監査支援システム開発
内部監査の指摘では、監査員の力量に左右されて的確な条項に基づく指摘が出来ていないのが実情である・・・今回、力量の不足をAIによって支援するシステムのモデルを構築する・・以下の課題は2点がメインだが、TAMの監査指摘4年分をデータ化し構造化することによって支援の形態が現実的に見えてきた
- AIに情報を渡すが、その情報が漏洩リスクとならないために、固有名詞などを送らせない
- 具体的な支援方法について、イメージが具体的にならない
内部監査システム構築のためのステップ
- STEP 1-1: 事実メモを箇条書きで入力(固有名チェックあり。通らないと進めない)
- STEP 1-2: AIが事実の不足を質問(最大3問×2ラウンド。スキップ可)
- STEP 1-3: 対話結果から事実文を自動文書化 → 監査員が修正・確定
- STEP 2: 条項候補Top-3+境界注記 → 選択または手入力
- STEP 3: ランク選択 → 指摘文案生成 → 修正
- STEP 4: 確定 → 事例DBに蓄積(次回のAI参照例に自動反映)
これまでに構築したもの
- [TAMの審査記録xlsx 4年分をデータ化してサンプルとする] : audit_case_extract(抽出+三段匿名化: パターン/辞書/ローカルLLM検査)
- [匿名化済み事例DB cases.csv 388件] :clause_bench(条項マッチング実力測定)
- [実測: ゼロショット85.5%/適合性系93.8% → RAGで88.1%・混同半減] :検討結果書(二層アーキテクチャ: 規格層=共通/流儀層=組織別)
- [audit_assist_proto(動くプロトタイプ)] :事実引き出し対話 → 匿名化ゲート → 条項候補 → 人間確定 → 事例蓄積(自己学習)
主要な実測値(仕様書の根拠数字)
- 条項マッチング(Top-3実務粒度): ゼロショット全体85.5% / 適合性系93.8%
- 粒度規約+TAM事例RAG(v2b): 全体88.1%、最大混同ペア(8.1↔6.1.2)半減
- ランク別定型句の対応(388件分析): 改善の機会=「推奨します」、観察事項= 「検討の余地があります」が相互汚染ゼロの完全分離 → 文章生成テンプレートに採用
- 適合性系(観察事項・懸念領域・改善指摘)と意見系(改善の機会・充実点)の 2群構造を確認 → ランクはAIが当てず、2分類推定+監査員選択の設計に
実地試用の状況と次回のTODO
済み: 2022年審査データで10件試用・・「力量ある監査員には良い指標」との評価・・記録済みデータ: confirmed_cases.csv・metrics.jsonl に実データ10件保持
次回確認すること:
- v1.1修正の適用確認(重要): v1.2完了報告にv1.1(過剰検知修正・許可ボタン・ ランク2分類化)の適用言及がない。「建築部」「工務課長」「2件の作業所」が ブロックされないか確認し、未適用ならv1.1指示書を先に適用させる
- 採用率18.2%の原因調査: 体感(「非常によくできている」、明確な条項誤りは1件)と 記録上の採用率18.2%が大きく乖離している。候補カードをクリックせず手入力で 条項を入れる操作習慣だと、候補が正しくても「手入力=不採用」と記録される。 metrics.jsonlの確定条項の生値と候補を突合し、指標定義の問題か候補品質の問題かを 切り分ける(次回セッションでmetrics.jsonlをアップロードすれば分析可能)
- 1.2の意地悪テスト: 最低品質のメモ(「・教育記録を確認 ・不十分」)への AIの質問が、TAMが新人に返す問いと一致するか 試用を10〜20件継続し、指標の推移を観察
暑い朝の散歩 ローカルLLM(Ollama)の構築

ローカルLLM(AI)の構築
ローカルLLMとして、Ollamaを選択、ローカルでOpenAI互換APIを提供、Laravelから通常のAPI呼び出しと同じ形式でローカルLLMを叩ける
インストールするWindowsPCは、・マザー 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で、GPUが少し不足気味だが、Ollama Qwen2.5 14B (Q4量子化 約9GB)が動きそうなのでインストールして試行する
Ollama本体のインストール
https://ollama.com/download/windows からOllamaSetuo.exeをダウンロード 実行してインストール、インストール後、Ollamaは常駐サービスとして起動します(タスクトレイにラマのアイコン)
NVIDIAドライバの確認
nvidia-smiを実行して、ドライババージョンとRTX 4070 Ti、VRAM 12288MiBが表示されればOK
モデルの取得と実行
ollama pull qwen2.5:14bをダウンロード完了したら、ollama run qwen2.5:14bで起動して、プロンプトから質問できる
GPU配分の確認
ollama psと入力して、OROCESSORが100%GPUとなっているので、VRAMに全部納まっている
API経由での動作確認(サーバ連携の予行)
Ollamaは自動的にhttp://localhost:11434でAPIを開いているので、Laravelから叩く検証ができる
Jeepの車検
今朝も暑い、キクを連れて元宇品を散歩、キクはタヌキを見つける・・・走りすぎてバテてました・・・午前中に、J58の車検に、無事に終わって、今回はブレーキオイルを入れ替えたので¥5万程、昼からNGIさんが訪ねて来て久しぶりに雑談


キクと散歩 工事一覧の変更
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日ズレ等
- トランザクション欠落が主要機能に多数(途中失敗で中途半端なデータが残る)
- 同時編集の保護が皆無(後勝ち上書きで先の編集が無警告で消える)。
J58フロントドライブシャフトブーツの交換
キクと元宇品

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


元宇品の散歩
建設アシストのコードのセキュリティ対策として、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 標準モーダル(フォーカストラップ付き) |
甲斐犬のキク
キクと朝の散歩
岩谷観音に登る
昨日に続き、天気が良いので、朝のキクの散歩を兼ねて、岩谷観音を登る・・良く登っていた山だが、記録を調べてみると2020/11/16が最後のようだ・・・途中の車の中で、朝食のおにぎりを食べて、水分峡の駐車場に車を停める、いつもは水分峡の入口から直行で登るが、今日は勾配の楽な道隆寺の霊場から登り始める・・やはり膝に力が入らないので、ゆっくりと休みながら登る・・・GWなので登山者も多い・・・久しぶりの山頂(標高400mほど)は快晴で気持ちが良い・・・広島市内が良く見えて展望が素晴らしい・・・9:47から登り始めて山頂は11:23で、90分かかって登ったとことになる
下りは、同じ道を下るが、下りの方が足が痛い
フラフラになって車に到着(11500歩)・・・家に帰り、我が家の温泉で体を癒す・・・でもかなりの筋肉痛


天狗城山に登る
2022/10/22 キクと一緒に天狗城山を登ったのが最後で4年間ほど、ご無沙汰・・・天狗城山は一気に約300mを登るの岩山・・・2022年の時も体力は無く登りに90分もかかっていた・・・それから前立腺癌のホルモン治療で体調がおかしくなり、筋肉も落ちて、膝の関節炎となり、歩くのもままならず、出張での駅の階段などは苦行で・・山などはとんでもない状態だった
そんな状態から最近は少し回復をして散歩もかなりの距離が歩けるようになっていた・・・何となく昼から、急に思い立ち甲斐犬のキクを連れて登る・・・膝も万全ではないので無理はできないが、休み休み上って、今回は山頂までは70分程、2021年の頃は40~50分ほどで登っていた・・・さすがに関節炎になってからは登れないと思っていたが、少し膝も回復して意欲も戻ってきたようだ・・・下りは転倒しないように注意して(ほとんど岩山は尻を落として下る)、ようやく車まで戻る
少しすると足の脛が痛い・・・登山をすると痛かったあの感覚は久しぶりだ




































































