今日は昼から鹿児島に出張、九州新幹線が普通なので、福岡空港から臨時便で鹿児島空港に行くことにする・・・久しぶりに福岡空港に来たが、分かりにくい、チェックインしても搭乗口が分からないので、左右にある出発保安検査所の南側から入ると、搭乗口は反対側の端だった・・・南側保安検査所まで、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呼び出しから効きます。版が記録され、履歴から復元もできます
パキラ
内部監査システムの改良
複数監査への対応
複数監査が実施されているときに、対象監査を明確にする
内部監査計画書一覧で監査計画選択を明確
内部監査計画でISOシステムを選択
今までは会社組織で設定してあるISOシステムをすべて監査計画に取り込んでいたが、特定のシステムだけの監査が可能にする
EMSだけの監査を可能にする
監査画面のモーダル化
処理として通常の画面からモーダル化によりUIを改善
| コード | 説明 |
|---|---|
| ORG-HOME-M1〜M5 | 会社概要の各編集モーダル（M4=マネジメントシステム設定、M5=部署別項目設定） |
| AUD-TMPL | チェックシート項目設定（会社概要から開く） |
| AUD-USER | 監査員設定（会社概要から開く） |
| AUD-SCH-M1／M2 | 監査予定の追加／編集 |
| AUD-HOME-M1 | 監査予定にない監査実施 |
| AUD-RPT-M1 | 監査完了 未達項目 |
| AUD-FIND-M1 | 監査指摘作成（新規追加・編集） |
| IA-MODAL | 指摘のAI支援ウィザード（IA-MODAL-S1〜S6） |
- 計画2件の状態でAUD-LISTから「監査予定表」タブを押しても、一意に決まらないためAUD-LIST自身に留まることを確認（誤誘導の解消）
- 計画詳細（1件に絞られた文脈）では「監査予定表」タブが正しくその計画へ直行することを確認
- AUD-CHK・AUD-FINDに「第1回内部監査」が表示されることを確認
- AUD-HOMEのタイトルが「監査実施一覧」に変わったことを確認
- AUD-CA-SELECT（管理者アカウント）で共通タブ5本が表示されることを再確認（段階17Cで未確認だった項目）
- マイグレーションなし（データ削除のみ、スキーマ変更なし）
ガジュマル
| コード | 画面名 | ルート名 | 補足 |
|---|---|---|---|
| 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の前半部分を分離 |
内部監査システムの再構築
監査システム全体のUI再構築
基本的なUIを整理
- タブメニューの並び(監査モジュール)
- 「戻る」ボタンの見直し
- 用語の統一
- 画面・モーダルの識別コード表示
- ボタンサイズの統一
- 監査ページの配色とコントラスト
個別監査の完了機構
以下をすべて満たすとき完了操作が可能:
- チェックリストが作成され、記入されている——段階6-Bの3段階判定で「記入済み」
- 不適合の指摘がある場合、その是正処置が完了している(完了月日が入力済み)。
不適合が0件の場合はこの条件は自動的に満たされる
監査計画ごとの対象ISOシステム選択
実務では「第1回はQMS/EMS/OHSMSの統合監査、第2回はEMSのみ」のように、監査計画ごとに対象規格が異なる（認証機関の審査でも一般的）。従来は会社が採用している全規格を計画へ自動同期しており、計画ごとに選べなかった。これを計画ごとの選択制に変更する
監査の流れの再構築と名前の統一
Palo Santo
今日は我が家の盆の法事、徳栄寺さんにお願いしてお参りしてもらう
内部監査システムの構築
盆に入ってから、本格的に内部監査のシステムの構築を始める・・ザッと思いつくままに構築はしたが、色々な課題が残っている
内部監査チェックリスト実態調査
関連テーブルの構造と関係: チェックリストのテンプレート(基本設定)側と、
監査実施ごとのインスタンス側の区別。audit_master_questions・
audit_checklist_templates・audit_checklists等の列構成・リレーション
- 「マトリックス」の実体: 規格条項×何か(業務種別?部署?)の対応が
どこにどう保持されているか。管理画面(基本設定)でマトリックス編集する
機能の有無と実装状態 - 監査実施時にチェックリストが作られる流れ: テンプレートからインスタンスが
生成されるタイミング・ロジック、業務種別タブの手動選択の実体 - 部署との連動の現状: 部署情報がチェックリスト選定に使われている箇所が
1つでもあるか。「構築したつもりが接続されていない」型の未配線
(画面はあるが参照されない設定、等)がないか - チェックリスト記入とAI支援・指摘作成の関係: チェック結果(evidence等)から
指摘への転記経路の有無
監査員、管理責任者、ISO規格改訂、AI支援の扱い
監査員補/監査員/主任監査員
管理責任者フラグの追加
ISO 規格改訂への対応
AI入力支援との関連
既存監査報告書の再構築
- 監査計画書(計画そのものの内容: 目的・範囲・基準・重点事項・期間など)
- 部署監査計画/報告書リスト(配下の個別監査の一覧。各行の状態表示と導線)
- 監査指摘統合一覧+全合計(全部署・現場を統合した指摘一覧と集計)
監査クローズの設定
監査計画書にすべて完了したことを表示してCloseボタン設定
監査予定表の設定
管理責任者が監査計画の配下で「いつ・どこを・誰が監査するか」の予定表を作り、監査員は監査実施ホームで自分の担当を見て監査に入る。予定表は監査員への「配布物」であり、予定と実績のずれの管理は行わない
法事
誕生日会
