今日は曇りだが、昼過ぎにはかなりの雨が降った
今週は週末まで天気は悪そうだ・・・暑さが和らぐならば歓迎ですね
そろそろ小規模事業者補助金の採択後の本見積を本気でしなくてはならないが、厨房と1Fのカウンターの平面計画が中々決まらないので・・・・もう5案も作成したが、どうやら納得できそうな計画が決まったので、厨房器具を配置して、最終見積を依頼する
10月の初めに企業のISO研修を頼まれているので、PPTを作成して、校正をClaudeに依頼する・・・しっかりと誤字、脱字、Noの間違い、解釈の揺れを指摘してくれて、その後修正も自動で実施、楽になったものだ
帰りは八幡浜で特急の待ち時間が45分、一時間に1本なので便が悪い・・・ようやく乗って、またJR松山駅から歩いて伊予鉄に乗って、連絡バスで松山観光港に、リニアジェットは30分の待ち時間・・・・16時に出発して広島港には､19:50到着・・・前の特急に乗れてもリニアジェットの接続便が無いため、松山観光港で待つことになり、同じだった
今回はキャリケースのカバンのハンドルが壊れて、カバンをキャリーできなくなり、持って出の移動となり、暑さも一緒になって・・・・疲れました
八幡浜での最初の日は、佐田岬の三崎に・・・暑い、海が奇麗なので泳いだら気持ちが良いだろうな
八幡浜の宿泊は、いつもと違って駅前のホテルがリニューアルされたので、そちらに・・・八幡浜は良いホテルが無く、ホテルの予約も取りにくい・・・今回のホテルは、食堂で日本酒と果樹酒が飲み放題だった
夕食はもう一人のメンバーと食堂で一杯
今日は15時から八幡浜に出張に、ここの組織ももう10年以上審査している
宇品港からは新しいリニアジェットが就航していたが、前のスーパージェットより料金が値上げされて、所要時間は10分ほど余分ににかかって1時間20分で、松山観光港に、ここではリムジンバスが廃止となっているので、連絡バスで高浜港に行き、伊予鉄で大手町に、ここから1km以上歩いてようやくJR松山駅
JR松山駅は高架になって、駅も新しくなったが、前の場所よりかなり遠くなった
ギリギリで特急に乗る、乗り遅れると1時間は待たなくてはならない
八幡浜の駅は時代に取り残されたよう
Laravelに付属する開発用の簡易サーバ
ブラウザ → localhost:8000 → PHPの内蔵サーバ → アプリ
コマンドを打っている間だけ動き、ウィンドウを閉じると止まる
8000 はポート番号で、同じPC内で複数のサーバを区別する番号です。アプリを2つ動かすなら 8000 と 8001 のように分けます。
常駐型のWebサーバで、バックグラウンドで動く
ブラウザ → XXXX.test → hosts → 127.0.0.1 → Herd(nginx) → PHP → アプリ
これはデータベースだけを担当します。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がすること | 監査員がすること |
|---|---|
| 事実が十分か確認する質問を出す | 質問に事実で答える |
| 事実を監査記録の文体に整える | 内容を確認・修正する |
| 該当しそうな規格条項を3つ提示する | どの条項にするか決める |
| 指摘文の案を作る | 文面を確認・修正して確定する |
AIは「答えを出す装置」ではなく、監査員が見落としがちな点を問い、 候補と根拠を示し、文章化の手間を減らす役割
AIの提案に対する反論
誤った反論が通らない設計– 誰でも反論できますが、通るのは規格に照らして正しい反論だけ—これによって、間違った学習が防がれます
| 応答 | 意味 | 対応 |
|---|---|---|
| 認める | 反論が正しい。修正案を提示 | 「この内容で生成し直す」を押す |
| 部分的に認める | 争点の一部だけ修正 | 内容を見て判断 |
| 維持する | 反論が誤り、または根拠不足。理由を示して現状維持 | 納得すれば従う。しなければ手で編集 |
AI支援の判断規律を定める「解釈原則」は現在、Dropbox内のマークダウンファイルを直接編集し php artisan ia:import-principles –force で投入する運用になっている・・・このため原則を1行足すのにファイル編集とコマンド実行が必要で、監査作業の流れが途切れる・・・原則を画面から編集できるようにし、気づいた瞬間に追記できる状態にする
| 種別 | 編集できる人 | 効果範囲 |
|---|---|---|
| 共通原則(company_id = NULL) | システム管理者(role=1)のみ | 全テナント |
| テナント原則(company_id = 値) | 管理責任者 / 会社管理者 | 自社のみ |
会社概要ページの「内部監査」カードに「解釈原則設定」ボタンを追加する。
現在の原本は Dropbox 内の audit_assist_proto/principles/audit_principles.md
画面編集を導入するとDBが原本になり、ファイルとの二重管理になる。
現在の原本は Dropbox 内の audit_assist_proto/principles/audit_principles.md
画面編集を導入するとDBが原本になり、ファイルとの二重管理になる
原則集のマークダウンをリポジトリ内に移す
(例: docs/audit_principles.md)。機密ではないためgit管理して問題ない
| 原則udit_principles.md | 憲法に当たるものであり、常に効く、判断の規律を伝える | 原則にすべきもの: 同じ型の誤りが2回以上起きた 規格の記述に基づいて一般化できる 審査員としての規律に関わる(過大解釈の抑制、表現の強度など) |
| 事例 | 判例であり、似たときだけ効く、具体的な紐づけと力点を伝える | 指摘を「決定・保存」すると、その判断が次回以降の参考事例になります–特別な作業は不要です。監査業務そのものが教材を生みます |
原則は事例の誤りを打ち消せます–事例に古い判断が混じっていても、原則が効いてAIはそれを真似しません
原則については、AIの判断に繰り返し違和感があるとき、原則を1行足します
「解釈原則設定」→ 編集して保存
次のAI呼び出しから効きます。版が記録され、履歴から復元もできます
複数監査が実施されているときに、対象監査を明確にする
内部監査計画書一覧で監査計画選択を明確
今までは会社組織で設定してある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） |
| コード | 画面名 | ルート名 | 補足 |
|---|---|---|---|
| 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の前半部分を分離 |
以下をすべて満たすとき完了操作が可能:
実務では「第1回はQMS/EMS/OHSMSの統合監査、第2回はEMSのみ」のように、監査計画ごとに対象規格が異なる（認証機関の審査でも一般的）。従来は会社が採用している全規格を計画へ自動同期しており、計画ごとに選べなかった。これを計画ごとの選択制に変更する
今日は我が家の盆の法事、徳栄寺さんにお願いしてお参りしてもらう
盆に入ってから、本格的に内部監査のシステムの構築を始める・・ザッと思いつくままに構築はしたが、色々な課題が残っている
関連テーブルの構造と関係: チェックリストのテンプレート(基本設定)側と、
監査実施ごとのインスタンス側の区別。audit_master_questions・
audit_checklist_templates・audit_checklists等の列構成・リレーション
監査員補/監査員/主任監査員
管理責任者フラグの追加
ISO 規格改訂への対応
AI入力支援との関連
監査計画書にすべて完了したことを表示してCloseボタン設定
管理責任者が監査計画の配下で「いつ・どこを・誰が監査するか」の予定表を作り、監査員は監査実施ホームで自分の担当を見て監査に入る。予定表は監査員への「配布物」であり、予定と実績のずれの管理は行わない
監査で使用する固有名詞等を匿名化してAIに送るシステム
雑用がようやく片付いたので、再びClaudeで内部監査システムの構築を始める
監査での事実をClaudeのLLMで、条項及び指摘分を作成するシステムのテスト運用が終わったので、いよいよ建設アシストの内部監査に組込みを実施
Claude-Webで実施計画を検討して、Claude Codeへの実装指示書を作成、その指示書を実行させ、実際のコードをもとに計画書を作成させて、課題・懸念事項などを再びClaude-Webで検証させ、TAMが判断と指示をする
この繰り返して、コードの実装を行ってゆく
カレー店舗の補助金の本採択に向けて見積書を作成する必要があるが、その前に厨房の平面図を決定しておくことが必要となる・・・色々と検討して、2回目に作成した平面計画を捨てて、新しい平面計画を作成、ポイントは、前回案は厨房を1階ホール側に大きくはみ出して、厨房の面積が大きかったのを、最小限に小さくする・・・・このことにより、不要な厨房器具を最小限にする・・・現地の寸法を再び測定して間違えの無いことを確認する・・この配置案をもとに、厨房機器の見積を三社に依頼、ネット通販の1社からはすぐ見積が送ってきた
三社が出そろったら、ネット申請をしてその結果を待つことになる
4月末に申請していた、小規模事業者持続化補助金の第19回目の採択の発表が、7月末にあり、申請した店舗の厨房器具が採択された・・さっそく見積を用意しなくてはならないが、事務局に電話して内容を確認して、もう一度、計画を見直しするために、厨房図面を修正する・・・だいたい、配置が決まったので、見積の徴収をしなくては
カレー店舗開店のための一つのハードルがクリアできたので、3月末オープンに向けて張り切らなくては
久しぶりに横川のQMACの事務所により、QMACのHPに関する打合せ
今までQMACのHPの維持をしていたが、何かがあった時に迷惑をかけてはいけないので、TAMもこの辺で区切りをつけて、少しづつ業務を少なくして行く・・そろそろ引き際の時期です
HPは業者に移管することにしたが、金額が高いので、TAMがHPをWerdPressで作り直して、HPの更新は事務局が実施することにする
ITOさんも、事務局長のKNMさんも9月末でQMAC事務局から退職して、新体制となる
そのためには、新しいHPは、新しくサーバーを契約しなおして、そのサーバーに新しいHPをインストールすることにする・・・そんな打ち合わせを夕方までして、その後は、いつもの流れで、ITOさんと横川で食事（スペイン料理だったが、あまりぱっとしなかった）をして、振りが付いたので、LIGHT HOUSEで一杯飲んでゆく
