コメントはありません
J58にシートスライドレールを付ける
キクと元宇品の散歩
J58運転席のシートフレームの取付け
京橋川の土手を散歩
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つ（取り消し可）に集約
| 更新の担い手 | 事務局 |
| 行事の追加 | 管理画面で入力 |
| 年度末の切替 | ボタンで切り替え |
| 過去年度リンク | 完全自動 |
| 写真の掲載 | ドラッグで追加（自動圧縮） |
| スマホ対応 | あり |
鹿児島から広島に
今日は一日、鹿児島で仕事だが、昼から現場確認に、東シナ海側の吹上浜（加世田市）に行く、吹上浜は久しぶりですね
2005年に、HHM、SDK、SEI、TAMの4人で、薩摩半島のキャラバンに行っています
２月の連休は暖かい薩摩半島の南端に温泉ざんまい
仕事は少し早く終わったが、飛行機の便は無いので予定通りの便で帰宅に
鹿児島に出張
今日は昼から鹿児島に出張、九州新幹線が普通なので、福岡空港から臨時便で鹿児島空港に行くことにする・・・久しぶりに福岡空港に来たが、分かりにくい、チェックインしても搭乗口が分からないので、左右にある出発保安検査所の南側から入ると、搭乗口は反対側の端だった・・・南側保安検査所まで、100ｍ歩き、保安検査所から搭乗口までは250ｍ歩く
鹿児島空港からはバスで、鹿児島中央駅に、ホテルは駅の横を予約
キクの散歩と高圧洗浄機
月曜にはJSAにセミナー資料を送付するために、1日編集作業・・・AIで調べさせてスピードアップ
広島競輪場 建設アシストのWebsiteのSEO対策
最初の予定通り、回転ずしに・・・ここも超満員で30分ほど待ちました
対象：https://sys-assist.co.jp/（WordPress / Parabolaテーマ）
作業一覧
| サイトタイトルの全角スペース削除 | 管理画面 |
| キャッチフレーズ設定 | 管理画面 |
| サンプル投稿「Hello world!」とコメントの削除 | 管理画面 |
| コメント機能の全面停止 | 管理画面 |
| 開発者プロフィールページの新設 | 固定ページ |
| 会社概要ページの新設 | 固定ページ |
| ISO 14001:2026改訂の解説記事を公開 | 固定ページ |
| SEO基盤の導入（メタ情報・OGP・構造化データ） | mu-plugin 1ファイル |
| プロフィール写真とOGP画像の作成 | 画像加工 |
| 見出し・表・段組みの表示調整 | 追加CSS |
| 日本語URL 4本の英字化 | 管理画面 |
| 旧URLから新URLへの301リダイレクト | Redirectionプラグイン |
| パーマリンク構造を「投稿名」に変更 | 管理画面 |
| Google Search Console の登録 | 外部サービス |
| サイトマップの404不具合の修正と送信 | | | mu-plugin修正 |
個別の施策の意味
meta description
検索結果に表示される説明文です。順位そのものには影響しませんが、クリックされるかどうかを決めます・・今回はページごとに手動で設定しました・・設定していないページは本文の冒頭120文字が自動で使われますが、それでは表の中身が流れ込むなど、不適切な文章になることがあります
OGP（Open Graph Protocol）
SlackやTeams、LINE、X などにURLを貼ったとき、タイトル・説明文・画像のカードとして表示させるための情報です・・BtoBでは、担当者が社内チャットにURLを貼って共有する場面が必ずあります・・ここで無地のリンクが出るか、製品名と写真の入ったカードが出るかで、受け手の反応が変わります・・今回、1200×630ピクセルのOGP画像を作成しました
構造化データ（JSON-LD）
人間には見えない、機械向けの説明書きです。ページのHTMLに埋め込まれ、Googleに次のような情報を明示的に伝えます。
| Organization | 有限会社システムアシストという組織が運営している |
| WebSite | このサイトの正式名称は「建設アシスト」である |
| SoftwareApplication | 建設アシストは業務用のソフトウェア製品である |
| WebPage / BreadcrumbList | このページの位置づけと階層 |
文章から推測させるのではなく、決まった形式で直接伝えるため、誤解が起きません。将来的に、検索結果でのリッチな表示（星評価や階層表示など）の土台にもなります
見出し構造（h1 / h2 / h3）
見出しは文字を大きくする装飾ではなく、文書の階層を示す指定です。h1が章、h2が節、h3が項にあたります・・Googleはこの階層を読んで文書の構成を把握します。h1の次がいきなりh5だと、「大見出しが存在しない文書」と解釈されます・・文字の大きさはCSSで自由に変えられます。 見た目のためにタグのレベルを下げる必要はありません。今回、追加CSSでh2を約20pxに調整し、タグは正しい階層のまま使えるようにしました
301リダイレクト
転居届にあたります。 「このURLは、この新しいURLに恒久的に移りました」という宣言です・・301（恒久的）と302（一時的）があり、URL変更時は301を使います。Googleは301を見て、旧URLの評価を新URLに引き継ぎます・・設定しないと、旧URLはただの404（ページなし）になります。これまでに得た評価も、他サイトからのリンクも、すべて失われます・・今回は4本のURLを変更したため、Redirectionプラグインで301を設定しました。
日本語URLを英字にした理由
日本語のURLは、コピーすると次のように変換されます
https://sys-assist.co.jp/%e5%bb%ba%e8%a8%ad%e3%83%97%e3%83%ad%e3%82%b8…
これが200文字以上続きます。メールに貼っても、資料に載せても読めません。他サイトからリンクを張ってもらう際にも敬遠されます・・・投稿が0件の今のうちに変更したのは、影響を受けるURLが最も少ないタイミングだったためです。 記事が増えてから変更すると、大量の301を管理することになります
サンプル投稿の削除
「Hello world!」は、WordPressをインストールすると最初から入っているサンプル記事です・・・これが公開されたまま残っているサイトは、「作りかけで放置されている」と判断されます・・人間にもクローラにも、同じ印象を与えます。SEOの技術論以前の問題として、削除が必要でした
SEOとは何をすることなのか
「SEO対策」という言葉は範囲が広すぎて、何をしているのか分かりにくくなります。実際には、性質の違う4つの層に分かれています。今回の作業も、この4層のどこかに必ず属しています。
層1 見つけてもらう（クロールとインデックス）
Googleは「クローラ」というプログラムを走らせ、Web上のページを片端から読み込んでいます。読み込んだページを整理して保管することを「インデックスに登録する」と言います
インデックスに登録されていないページは、検索結果に絶対に出ません。 順位が低いのではなく、そもそも存在しないものとして扱われます
今回この層に効いた作業
・サイトマップの修正と送信（#15, #14）
・日本語URLの英字化（#11）
サイトマップは「このサイトにはこういうページがあります」という一覧表です。これがGoogleに届いていなければ、クローラは自力で探し回るしかありません・・実際、今回のサイトではサイトマップが404エラーを返しており、Googleが一覧表を受け取れない状態でした
層2 内容を正しく伝える
インデックスに登録されても、Googleが「このページは何について書かれているか」を誤解すれば、見当違いの検索キーワードで表示されてしまいます
ここで働くのが、ページの見出し構造とメタ情報です
今回この層に効いた作業
・meta description の設定（#8）
・見出し構造の整理（#10）
・構造化データ JSON-LD の出力（#8）
・サイトタイトルの修正（#1, #2）
層3 信頼される
Googleは近年、「誰が書いたのか」を強く見ます。 E-E-A-T（経験・専門性・権威性・信頼性）と呼ばれる評価軸です
特に、お金や健康や安全に関わる分野では厳しく評価されます。建設業の安全管理と法規制は、まさにこの分野です。 匿名の記事と、17年間・延べ630回の審査経験をもつ主任審査員が書いた記事とでは、扱いが変わります
ただし、Googleは経歴を推測してくれません。サイトに書いていなければ、存在しないのと同じです
今回この層に効いた作業
・開発者プロフィールページ（#5）
・会社概要ページ（#6）
・構造化データによる組織情報の明示（#8）
作業前のサイトには、誰が作っているのか、どこの会社なのかが一切書かれていませんでした。これはSEO以前に、人間の読み手が判断できない状態でした。
層4 選ばれる
Googleは近年、「誰が書いたのか」を強く見ます。 E-E-A-T（経験・専門性・権威性・信頼性）と呼ばれる評価軸です
特に、お金や健康や安全に関わる分野では厳しく評価されます。建設業の安全管理と法規制は、まさにこの分野です・・匿名の記事と、17年間・延べ630回の審査経験をもつ主任審査員が書いた記事とでは、扱いが変わります・・ただし、Googleは経歴を推測してくれません・・サイトに書いていなければ、存在しないのと同じです
今回この層に効いた作業
・title の整理（#1, #8）
・meta description の設定（#8）
・OGP画像の作成（#9）
実測での変化
| ページ数 | 5（うち1件はサンプル投稿） | 8 |
| <title> | 建設アシスト …（先頭に全角空白4個） | 建設作業所の法規制・安全管理をAIで支援するクラウドシステム |
| meta description | 0件 | 全8ページに出力 |
| OGP / Twitter Card | 0件 | 全ページに出力 |
| 構造化データ（JSON-LD） | 0件 | 全ページに出力 |
| URL形式 | 日本語（1本あたり200文字超） | 英字（/about/ /company/ 等） |
| サイトマップ | Googleが取得できない状態 | 正常に処理・登録済み |
| Google Search Console | 未登録 | 登録済み・サイトマップ送信済み |
雨のみなと公園 QMAC品質研究会
何となく今週は忙しかった
今日は昼からQMACの品質研究会の2回目、アドバイザーで出席・・・終わってからは、懇親会・・いつもの場所で
今日は一日雨が降っているな
鳥取から広島に帰る
朝カレーセット￥650は安い
新幹線に乗り換えて広島
鳥取に出張
今日は昼から鳥取での仕事なので、昼前に出かける
仕事は夕方に終わり、予約していたホテルに行くと・・・予約が無い
よくよく確認してみると9/2なのに10/2で予約していました・・・焦って宿泊場所を探すが、ホテルはどこも満室だ、￥32000のホテルはあったが論外、あとはカプセルホテルかゲストハウスしかないと・・・探していたら寿司屋が旅館をしているのが宿泊できそう・・・少し歩くことになるが、汗だくで到着・・・風呂は銭湯の温泉に
久しぶりに木賃宿で寝ることに
広島から鳥取には交通の便が良くない
岡山から鳥取には特急いなばがあるが、便数は少ない
特急いなばは、上郡で山陽線から智頭急行線を走る
上郡で進行方向が反対になるので、椅子を回転する必要がある
QMACのセミナーに参加
H-J58のBRIDEシートへ交換
元宇品の散歩
五日市の埋立を散歩
キクの散歩
システム言語の研究
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の固定費に慣れていると読みにくい。数社規模なら安いですが、予測可能性は下がります。
甲斐犬のキクと朝の散歩
今日は曇りだが、昼過ぎにはかなりの雨が降った
今週は週末まで天気は悪そうだ・・・暑さが和らぐならば歓迎ですね
そろそろ小規模事業者補助金の採択後の本見積を本気でしなくてはならないが、厨房と1Fのカウンターの平面計画が中々決まらないので・・・・もう5案も作成したが、どうやら納得できそうな計画が決まったので、厨房器具を配置して、最終見積を依頼する
10月の初めに企業のISO研修を頼まれているので、PPTを作成して、校正をClaudeに依頼する・・・しっかりと誤字、脱字、Noの間違い、解釈の揺れを指摘してくれて、その後修正も自動で実施、楽になったものだ
甲斐犬のキクと散歩
八幡浜から広島に
帰りは八幡浜で特急の待ち時間が45分、一時間に1本なので便が悪い・・・ようやく乗って、またJR松山駅から歩いて伊予鉄に乗って、連絡バスで松山観光港に、リニアジェットは30分の待ち時間・・・・16時に出発して広島港には､19:50到着・・・前の特急に乗れてもリニアジェットの接続便が無いため、松山観光港で待つことになり、同じだった
今回はキャリケースのカバンのハンドルが壊れて、カバンをキャリーできなくなり、持って出の移動となり、暑さも一緒になって・・・・疲れました
佐田岬の三崎に
八幡浜での最初の日は、佐田岬の三崎に・・・暑い、海が奇麗なので泳いだら気持ちが良いだろうな
八幡浜の宿泊は、いつもと違って駅前のホテルがリニューアルされたので、そちらに・・・八幡浜は良いホテルが無く、ホテルの予約も取りにくい・・・今回のホテルは、食堂で日本酒と果樹酒が飲み放題だった
夕食はもう一人のメンバーと食堂で一杯
八幡浜に出張
今日は15時から八幡浜に出張に、ここの組織ももう10年以上審査している
宇品港からは新しいリニアジェットが就航していたが、前のスーパージェットより料金が値上げされて、所要時間は10分ほど余分ににかかって1時間20分で、松山観光港に、ここではリムジンバスが廃止となっているので、連絡バスで高浜港に行き、伊予鉄で大手町に、ここから1km以上歩いてようやくJR松山駅
JR松山駅は高架になって、駅も新しくなったが、前の場所よりかなり遠くなった
ギリギリで特急に乗る、乗り遅れると1時間は待たなくてはならない
八幡浜の駅は時代に取り残されたよう
庭の百日紅
ウイスキーでハイボール
PHPアプリをローカルで開発する環境
PHPアプリをローカルで開発する環境
PHPアプリをローカルで動かすには
- PHP — コードを実行する
- Webサーバ — ブラウザからの要求を受け取り、PHPに渡す
- データベース — データを保存する
方式A：php artisan serve（localhost:8000）
Laravelに付属する開発用の簡易サーバ
ブラウザ → localhost:8000 → PHPの内蔵サーバ → アプリ
コマンドを打っている間だけ動き、ウィンドウを閉じると止まる
- 利点 — 設定不要。すぐ起動できる
- 欠点 — 1度に1リクエストしか処理できない（同時アクセスに弱い）、本番と構成が違う。ポート番号がURLに出る
8000 はポート番号で、同じPC内で複数のサーバを区別する番号です。アプリを2つ動かすなら 8000 と 8001 のように分けます。
方式B：Herd（.test ドメイン）
常駐型のWebサーバで、バックグラウンドで動く
ブラウザ → XXXX.test → hosts → 127.0.0.1 → Herd(nginx) → PHP → アプリ
- 名前解決 — qmac.test を自分のPC（127.0.0.1）に向ける
- Windowsの hosts ファイルに 127.0.0.1 qmac.test と書かれることで実現します。herd link を実行したときに Herd が自動で書き込みます。
- 振り分け — どのフォルダを見せるか決める
- herd park でフォルダを登録すると、その配下の各フォルダがフォルダ名.test で自動的に開けるようになります。C:\Users\syste\Herd を park してあるので、その中の XXXX が XXXX.test になりました。
- 利点 — 常時起動。複数サイトを同時に動かせる。本番に近い構成（nginx＋PHP-FPM）。ポート番号が要らない
- 欠点 — 最初の設定が要る。名前解決でつまずくことがある
DBngin の役割
これはデータベースだけを担当します。Webサーバとは無関係です
アプリ → 127.0.0.1:3306 → MariaDB
複数のバージョン（MySQL 5.7 / 8.0 / MariaDB 10.11 …）を並べて入れ、必要なものだけ起動できるのが特徴です。本番と同じバージョンを選べるので、XXXXX_app では 10.11 系を選びました。
停止していると、アプリは起動してもデータベース接続エラーになります
Herd と DBngin の両方が起動していないと動きません。片方だけだと、サイトは開くがデータが出ない、あるいはそもそも開かない、という状態になります。
php artisan serve は「ちょっと動かす」用、Herd は「開発環境として据える」用、という使い分けです。今回のように複数プロジェクトを並行させるなら Herd が向いています。
唐津に出張 佐賀に
盆明けには出張となる
まずは唐津に、博多で地下鉄空港線に乗換筑前前原で筑肥線に乗換て唐津に、唐津から乗り換えて西唐津・・新幹線で博多までは1時間ちょっとだが、博多から西唐津までは2時間以上かかる
夕方は西唐津から佐賀までは唐津線で1時間半、ここは電化されていないのでジーゼル
ホテルは駅から少し離れている
明日は佐賀で仕事をして夕方には広島に帰る
比治山の散歩
審査機関向け審査システムの構築
構築工程
MariaDB 10.11.11 上で稼働
| 段階 | 内容 | 状態 |
|---|---|---|
| 段階1 | fork と不要モジュール削除 | 完了（12コミット / −38,485行） |
| 段階2 | テナント解決の起点変更と顧客マスタ | 完了 |
| 段階3-0 | MariaDB 切替 | 完了 |
| 段階3-1〜3-6 | 審査構造への再編 | 完了 |
| 段階4 | 申込フロー再構築・ランク語彙 | 未着手 |
| 段階5 | RiskAssessment / Project 削除・匿名化辞書 | 未着手 |
| 段階6 | AI支援の語彙・解釈原則の追記 | 未着手 |
監査システムからの変更点
被審査組織は台帳である・・審査機関にとって被審査組織は登録番号・初回認証日・認証範囲を持つマスタであり、審査計画の副産物として属性が空のレコードが増える構造にはできない・・・認証契約に基づいて台帳に登録し、それから審査計画を立てる順序が実務に合う
| 仕様書 | 当初 | 確定 |
|---|---|---|
| §2.2 | client_sites（有期事業所マスタ）を新設 | 中止。審査対象は自由記述で足りる |
| §2.3 | audit_no を varchar 化して回次を保持 | audit_type へリネーム。自動採番も廃止 |
| §2.4 | 審査チームはaudit_reports 配下のまま | audit_plan_auditors へ移設（審査単位で任命） |
| §4 | チェックリスト3段構造をそのまま使う | 全面撤回。質問マスタ・テンプレート機構を全廃 |
| §8 | AUD-RPT を個別審査の計画・報告書として維持 | 画面ごと廃止。階層が1段浅くなった |
| §2.1 | 被審査組織を自由記述入力→自動登録 | 不採用CLI-EDIT に一本化（台帳の質を守るため） |
| 段階3指示 | AUD-HOME を AUD-PLAN 配下へ | 据え置き。AUD-RPTS が既に役割を果たしていた |
盆が終わった月曜日
甲斐犬のキク 叔父さんの墓参り
肖像画 監査における指摘に対するAI支援
内部監査AI支援 — 使い方と考え方
AIは判断材料を整え、判断は監査員が下す–これが全体を貫く原則
| AIがすること | 監査員がすること |
|---|---|
| 事実が十分か確認する質問を出す | 質問に事実で答える |
| 事実を監査記録の文体に整える | 内容を確認・修正する |
| 該当しそうな規格条項を3つ提示する | どの条項にするか決める |
| 指摘文の案を作る | 文面を確認・修正して確定する |
AIは「答えを出す装置」ではなく、監査員が見落としがちな点を問い、 候補と根拠を示し、文章化の手間を減らす役割
AIの提案に対する反論
誤った反論が通らない設計– 誰でも反論できますが、通るのは規格に照らして正しい反論だけ—これによって、間違った学習が防がれます
| 応答 | 意味 | 対応 |
|---|---|---|
| 認める | 反論が正しい。修正案を提示 | 「この内容で生成し直す」を押す |
| 部分的に認める | 争点の一部だけ修正 | 内容を見て判断 |
| 維持する | 反論が誤り、または根拠不足。理由を示して現状維持 | 納得すれば従う。しなければ手で編集 |
監査におけるAIによる解釈原則
AI支援の判断規律を定める「解釈原則」は現在、Dropbox内のマークダウンファイルを直接編集し php artisan ia:import-principles –force で投入する運用になっている・・・このため原則を1行足すのにファイル編集とコマンド実行が必要で、監査作業の流れが途切れる・・・原則を画面から編集できるようにし、気づいた瞬間に追記できる状態にする
| 種別 | 編集できる人 | 効果範囲 |
|---|---|---|
| 共通原則(company_id = NULL) | システム管理者(role=1)のみ | 全テナント |
| テナント原則(company_id = 値) | 管理責任者 / 会社管理者 | 自社のみ |
会社概要ページの「内部監査」カードに「解釈原則設定」ボタンを追加する。
- 表示条件: 管理責任者 / 会社管理者 / システム管理者
- 既存の「監査員設定」(AUD-USER)と並べて配置し、同じ扱いにする
- 共通原則: システム管理者でログインしている場合のみ [編集][削除][＋追加] を表示
- 自社の追加原則: 管理責任者・会社管理者に [編集][削除][＋追加] を表示
- 章立て(■1.、■2.…)は本文中の見出しとして扱う——現在の原則集はマークダウンの見出し+番号付き項目という構造なので、無理にDB上で章と項目に正規化せず、1レコード=原則集全体のテキストという現行構造を維持する(ia_principles.body は既にテキスト全体を保持している)
現在の原本は Dropbox 内の audit_assist_proto/principles/audit_principles.md
画面編集を導入するとDBが原本になり、ファイルとの二重管理になる。
現在の原本は Dropbox 内の audit_assist_proto/principles/audit_principles.md
画面編集を導入するとDBが原本になり、ファイルとの二重管理になる
原則集のマークダウンをリポジトリ内に移す
(例: docs/audit_principles.md)。機密ではないためgit管理して問題ない
- ファイルは初期投入用のシードと位置づけ、以後の編集は画面から行う
- ia:import-principles コマンドは新規環境の初期セットアップ用として残す
(本番デプロイ時の初回投入に使う) - この位置づけを README またはコマンドのdocblockに明記すること
AIを育てる — 2つの経路
| 原則udit_principles.md | 憲法に当たるものであり、常に効く、判断の規律を伝える | 原則にすべきもの: 同じ型の誤りが2回以上起きた 規格の記述に基づいて一般化できる 審査員としての規律に関わる(過大解釈の抑制、表現の強度など) |
| 事例 | 判例であり、似たときだけ効く、具体的な紐づけと力点を伝える | 指摘を「決定・保存」すると、その判断が次回以降の参考事例になります–特別な作業は不要です。監査業務そのものが教材を生みます |
原則は事例の誤りを打ち消せます–事例に古い判断が混じっていても、原則が効いてAIはそれを真似しません
原則については、AIの判断に繰り返し違和感があるとき、原則を1行足します
「解釈原則設定」→ 編集して保存
次のAI呼び出しから効きます。版が記録され、履歴から復元もできます