内部監査支援(AI/IA支援)機能 引き継ぎメモ

(1)AI内部監査支援 実装済みコンポーネント一覧と場所

Phase1: 匿名化(マスキング)エンジン

監査で使用する固有名詞等を匿名化してAIに送るシステム

  • app/Services/InternalAudit/MaskingRuleEngine.php — 固有名詞検出エンジン本体。Python版audit_case_extract/masking_rules.py(rules.json v1.3)のPHP移植。検出のみ(置換はしない)
  • config/ia_masking_rules.json — ルール定義(35ルール、block 13 / warn 22)
  • tests/Unit/InternalAudit/MaskingRuleEngineTest.php/tests/Fixtures/ia_masking_test_vectors.json(50件、Python版と両方でPASS必須)
Phase2: データ基盤
  • migration 6本: 2026_08_08_100001〜100006(ia_reference_cases / ia_sessions / ia_dictionary_terms / ia_allowed_terms / ia_principles / ia_ai_logs)
  • モデル: IaReferenceCase(トレイトなし・全社共通の読み取り専用マスタ) / IaSession・IaDictionaryTerm・IaAllowedTerm・IaAiLog(BelongsToTenantDirect) / IaPrinciple(BelongsToTenantNullable、company_id NULL=共通・値ありはテナント)
  • app/Services/InternalAudit/BigramVectorizer.php — 文字バイグラム+TF-IDFコサイン類似度の共通処理
  • app/Services/InternalAudit/CaseSearchService.php — 類似事例検索(ia_reference_cases+テナント確定指摘の2種、テナント指摘を優先)
  • artisanコマンド: ia:import-reference-cases {csvPath} / ia:import-principles {mdPath} {–force}
  • config/audit.php に finding_rank_slots / reference_rank_slots / slot_groups / slot_expression_strength を追記
Phase3: AIサービス統合
  • app/Services/InternalAudit/AiGatewayService.php — 全AI呼び出しの唯一の経路。送信ゲート(MaskingRuleEngine)→AnthropicClient→ia_ai_logs記録→JSON解析失敗時1回だけ自動リトライ
  • ClarifyService.php(確認質問) / FactDraftService.php(事実文ドラフト) / CandidateService.php(条項候補Top-3+2分類推定+文書化根拠AI判定+手入力整合検証) / GenerateService.php(指摘文生成) / PrincipleProvider.php(解釈原則の取得結合)
  • app/Exceptions/MaskingGateBlockedException.php / AiJsonParseException.php
  • config/anthropic.php に internal_audit 用途を追記 / config/ia_support.php(用途別max_tokens、confusion_pairs)
  • app/Services/InternalAudit/IsoClauseCatalog.php — 条項マスタの実在番号一覧(TTL1時間キャッシュ)。Phase4.3で条項ハルシネーション対策として追加
  • app/Services/InternalAudit/TenantDictionaryProvider.php — block級テナント辞書の合成(手動登録ia_dictionary_terms+既存マスタ自動導出)。TTL10分、IaDictionaryTermの更新は即時キャッシュ無効化
Phase4〜4.3: 画面組み込み
  • app/Http/Controllers/IaSupportController.php — 9アクション(storeSession/check/clarify/factDraft/candidates/checkClauseFit/recordClauseFitDecision/generate/adopt/storeAllowedTerm)。ルートはroutes/web.phpのia_support.*(9本)
  • resources/views/audits/findings/_ia_support_modal.blade.php + resources/js/audits/ia-support.js — Alpine CSPコンポーネント(iaSupportModal)。STAGE 3-C方式(JSON設定タグ経由で設定値を受け渡し)
  • resources/views/audits/findings/edit.blade.php — 詳細編集モーダル(findingsEditor)に「✨ AI支援」ボタン。別AlpineスコープのiaSupportModalとはwindow.dispatchEventのカスタムイベント(ia-support:open-request / ia-support:applied)で疎結合連携
  • AuditFinding.php(ia_session_idをfillableに追加) / AuditFindingController.php(upsert時にia_session_idを素通し)
  • tests/Feature/IaSupportControllerTest.php(12件)

(4) 未対応の既知課題リスト

  1. IsoClauseCatalogキャッシュの無効化がCSV取込に連動していない。IsoClauseControllerの管理画面CSV全置換後、最大1時間は古い条項番号一覧のままになりうる(候補生成・手入力マスタ実在チェックの両方に影響)。Cache::forget(IsoClauseCatalog::cacheKey($code))をCSV取込処理に追加すべきだが未着手。
  2. モーダルを途中で閉じた場合、ia_sessions.status=0のまま残る(プロトと同じ既知の割り切り。クリーンアップ/バッチ処理は未実装)。
  3. AnthropicClientへのtemperature任意パラメータは未追加(Phase3完了報告の「将来の小改善候補」)。JSON解析失敗時の1回リトライで実運用上は担保しているが、応答安定性が問題化した場合は呼び出し元4箇所への影響を含めて検討要。
  4. ランクマスタの完全テナント可変化(ia_rank_master)は未着手。現状スロット対応はconfig/audit.phpのみで完結させており(Phase2完了報告に明記)、テナントごとのランク名称カスタマイズはPhase5相当として先送り。
  5. resolveAdoptedRank等のメトリクス(candidate_adopted_rank/group_selected等)は記録のみで分析・活用先が未実装。ia_sessionsに溜まっているだけで、これらを使った改善ループ(候補精度の可視化等)は今後の課題。
  6. Phase4.2/4.3は指示書のみでDropbox側の完了報告mdが作成されていない(本メモ作成時点で確認)。次に大きな変更を入れる際は、まずコード側コメント(IaSupportController/CandidateServiceのdocblock)を一次情報として参照し、必要なら完了報告を追補すること。

(2) 設計上の重要な規約

  1. AIはaudit_findingsに一切書き込まない。サーバ書き込みは既存の一括upsert API(AuditFindingController::update)のみ。IaSupportControllerはia_sessionsへの経過記録のみ行う。反映(adopt)後もクライアント側でfindingsEditorのフォームへセットするだけで、ユーザーが「決定・保存」を押した時点で初めて保存される。
  2. 送信ゲートの不変条件: AiGatewayService::send()に渡す$messagesは、実際にAnthropicClient::messages()へ渡すオブジェクトと完全に同一でなければならない。ゲート検査対象(extractUserText())と実送信内容が別経路で構築されることは厳禁(迂回防止)。新しいフィールド(部署名・条項等)を追加する場合は必ず各サービスのbuildUserPrompt()内で$messagesの文字列に組み込むこと。回帰はAiGatewayServiceTestで確認。
  3. doc_basisの(e)完全一致規約: docBasis === ‘(e)’の場合のみ意見系(改善の機会)調を適用する。それ以外の非空文字列(複数選択で(e)+他根拠を含む場合も含む)はすべて「根拠あり」として通常の指摘調になる。IaSupportController::resolveDocBasis()が唯一の解決箇所(改ざん耐性のためクライアントからはトグルの状態のみ受け取り、詳細文言はサーバ側保存済みのdoc_basis_judgmentから都度組み立てる)。
  4. 条項はマスタ実在のみ(IsoClauseCatalog::validClauseNumbers())。AI候補・手入力とも、実在しない条項番号はCandidateService::filterValidCandidates()で除外する(2026-08-08の条項ハルシネーション事故対応)。マスタが空(未整備)の場合は安全側でフィルタしない。除外時の代替候補への繰り上げはしない(見せる候補が減るだけ、TAM指定の方針)。
  5. ユーザーには事実のみを尋ね、判定はAIが提示する(CLAUDE.md原則の実装例)。文書化根拠(doc_basis_judgment)はAIが質疑応答から判定して宣言文で提示し、ユーザーは上書きトグルで検証・反転のみ行う(「根拠がありますか」とは質問しない)。手入力条項の整合検証も同様で、mismatch時は強制ブロックせず「選び直す/このまま生成する」の選択肢を提示するのみ(条項の最終権威は監査員)。
  6. warn級は自動伏字化、block級は修正必須(Phase4.3)。次ステップへ進む操作の時点で未処置warnヒットを○○(カテゴリ)形式へ自動置換し、以後の全処理(AI送信含む)にその置換後テキストを使う。warn_passed_countの意味は「無処置通過数」ではなく「自動伏字化数」(列コメント参照)。
  7. モデル自身の内部状態でウェイトUXを実装(ai_modal.blade.phpは使わない)。同一モーダル内で複数回AI呼び出しを行う多段ウィザードはai_modal.blade.php(単発処理→リダイレクト専用)と構造的に不適合なため、iaSupportModal自身のloading/timedOut/elapsedSecondsで待機UXを実装している(CLAUDE.md原則からの意図的逸脱、完了報告に理由記載済み)。

(3) 触ってはいけないもの/前提を誤解しやすいもの

  • database/seeders/IsoClauseSeeder.php は化石。初期セットアップのフォールバックに過ぎず、第2階層まで・要約文言なしの不完全データ。正式マスタはIsoClauseController.phpの管理画面CSV取込(指定ISOシステムの条項を全置換)であり、本番・開発とも既にCSV取込済みの充実データが入っている。環境再構築時にこのSeederだけを実行すると、既存マスタより貧弱なデータで上書きしてしまう。CSV原本はD:\Dropbox\03システムアシスト\00-Bulid-Assist\内部監査\のISO9001-2015_要求事項要約.csv等。
  • AuditFindingのclient_key対応バックエンドは意図的に残置。Phase4.3でopenCorrectiveReport()撤去に伴い現在フロントからの送信元は無いが、「未保存行から確定IDを引きたい」将来用途のためのバックエンド仕組みとして削除しない(AuditFindingController.phpのコメント参照)。
  • config/audit.phpのreference_rank_slotsのキーはia_reference_cases.rank_labelの実データ値そのもの(改善指摘A/改善指摘B/懸念領域/観察事項/改善の機会/充実点/参考)。既存finding_ranks(iso_app本体の語彙)とは別語彙であり、変換・正規化は一切していない。キー名を「綺麗に」リネームすると初期コーパスとの対応が壊れる。
  • FactDraftServiceは解釈原則(PrincipleProvider)を付加しない。Clarify/Candidate/Generateの3サービスとは非対称(app.py精読で判明した既存プロトの仕様を忠実踏襲。「揃えたほうが綺麗」に見えても直さないこと)。
  • IsoClauseCatalogはTTL1時間キャッシュだが、CSV取込側にキャッシュ無効化処理が無い(現状把握。詳細は(4)参照)。
  • similar_text()によるedit_ratioはバイト単位の近似値であり、Python版(difflib.SequenceMatcher、文字単位)との厳密一致は保証しない。単調性(修正が多いほど値が大きくなる)のみ担保。厳密な一致を要求する変更をしないこと。
  • AnthropicClient.php本体・既存4呼び出し元は無改修のまま。internal_audit用途はconfig追記のみで対応しており、system/temperatureパラメータをAPIに渡さない既存インターフェースを崩していない(IA側は役割定義+原則をuser roleメッセージ先頭に折り込む方式)。

Claudeで内部監査システムの構築

五日市の埋立を甲斐犬のキクと散歩

雑用がようやく片付いたので、再びClaudeで内部監査システムの構築を始める
監査での事実をClaudeのLLMで、条項及び指摘分を作成するシステムのテスト運用が終わったので、いよいよ建設アシストの内部監査に組込みを実施
Claude-Webで実施計画を検討して、Claude Codeへの実装指示書を作成、その指示書を実行させ、実際のコードをもとに計画書を作成させて、課題・懸念事項などを再びClaude-Webで検証させ、TAMが判断と指示をする
この繰り返して、コードの実装を行ってゆく

Claude Codeのターミナルの画面 PCのファイル操作ができる(Sonnet 5)
ClaudeのWeb画面(Fable-5) Fable-5にしていたら一気にトークンを消費した

カレー店舗の厨房配置図作成

キクの散歩は、近くの公園を・・・暑い

カレー店舗の補助金の本採択に向けて見積書を作成する必要があるが、その前に厨房の平面図を決定しておくことが必要となる・・・色々と検討して、2回目に作成した平面計画を捨てて、新しい平面計画を作成、ポイントは、前回案は厨房を1階ホール側に大きくはみ出して、厨房の面積が大きかったのを、最小限に小さくする・・・・このことにより、不要な厨房器具を最小限にする・・・現地の寸法を再び測定して間違えの無いことを確認する・・この配置案をもとに、厨房機器の見積を三社に依頼、ネット通販の1社からはすぐ見積が送ってきた
三社が出そろったら、ネット申請をしてその結果を待つことになる

店舗厨房の平面図 今回3回目の変更

元宇品の海岸 墓の掃除

元宇品の森から海岸に

4月末に申請していた、小規模事業者持続化補助金の第19回目の採択の発表が、7月末にあり、申請した店舗の厨房器具が採択された・・さっそく見積を用意しなくてはならないが、事務局に電話して内容を確認して、もう一度、計画を見直しするために、厨房図面を修正する・・・だいたい、配置が決まったので、見積の徴収をしなくては
カレー店舗開店のための一つのハードルがクリアできたので、3月末オープンに向けて張り切らなくては

今は海岸の遊歩道は通行止めとなっているので人はいない
静かな海岸を歩く
墓を掃除して、盆のための柵をセットする

QMACでHP打合せ

スリーシップス(THREE SHIPS)は、南アフリカのジェームズ・セジウィック蒸溜所が造る、12年 シングルモルト: アメリカンオーク樽などでじっくり熟成された、フルーティーで奥行きのある高級銘柄、力強く豊かな味わいだが、かなり個性的な味

久しぶりに横川のQMACの事務所により、QMACのHPに関する打合せ
今までQMACのHPの維持をしていたが、何かがあった時に迷惑をかけてはいけないので、TAMもこの辺で区切りをつけて、少しづつ業務を少なくして行く・・そろそろ引き際の時期です
HPは業者に移管することにしたが、金額が高いので、TAMがHPをWerdPressで作り直して、HPの更新は事務局が実施することにする
ITOさんも、事務局長のKNMさんも9月末でQMAC事務局から退職して、新体制となる
そのためには、新しいHPは、新しくサーバーを契約しなおして、そのサーバーに新しいHPをインストールすることにする・・・そんな打ち合わせを夕方までして、その後は、いつもの流れで、ITOさんと横川で食事(スペイン料理だったが、あまりぱっとしなかった)をして、振りが付いたので、LIGHT HOUSEで一杯飲んでゆく

久しぶりにLIGHT HOUSEにゆく

五味破風高原から馬籠宿、妻籠宿に

太陽が上がる前の破風高原のヤナギランの群生 幻想的でしたね・・また、来ることができるかな
中山道の馬籠宿で、甲斐犬のキクと三度笠 長い坂道の宿場町は疲れます
▶この続きを見る・・・・

白鳥から平湯を抜けて五味破風高原に

早朝、宿の前には蓮の花が満開
狭い道の登って、更に歩いて城に
B&B弥次右衛門の前で
五味破風高原は小雨でした
気温は20℃以下
八幡城(郡上)に登ります
山小屋を丸ごと貸していただけることに・・夕食はジンギスカンセットを購入してバルコニーで焼きます
▶この続きを見る・・・・

夏の避暑に 広島から白鳥に

今夜の宿は、白鳥のB&B弥次右衛門ではコーヒーの焙煎販売をしている
郡上八幡でかき氷、量が多い3人分はある
鯉が多く泳いでいる、いがわ小径を散策
▶この続きを見る・・・・

夏のキャンプ旅行

2026/7/25(土) 広島8:00==山陽自動車道==姫路=中国縦貫自動車道==中国自動車道==舞鶴若狭自動車道=近畿自動車道 =敦賀= 北陸自動車道 =福井北JCT==R158==道の駅 越前おおの 荒島の郷=九頭竜IC==588km–16:30白鳥==郡上八幡=いがわ小径=郡上踊り=白鳥

B&B 弥次右衛門 Rakuten

2026/7/26(日) 白鳥8:30==八幡城(郡上)==中部縦貫自動車道/東海北陸自動車==60km–9:10高山IC==平湯(ひらゆの森) ==80.0km-11:00松本IC====須坂長野東IC===91km–五味池破風高原(山小屋に宿泊)

五味池破風高原

2026/7/27(月) 五味池破風高原==渋湯温泉=地獄谷野猿公苑==志賀高原=熊の湯=草津白根==万座温泉=嬬恋高原=つまごいパノラマライン=菅平=須坂==五味池破風高原

五味池破風高原

2026/7/28(火)五味池破風高原7:00==駒ヶ根==天竜峡==馬籠宿=妻籠宿==恵那市 恵那はなれの宿

恵那はなれの宿

2026/7/29(水) 恵那8:30==中央道==土岐JCT=東海環状自動車道=豊田東JCT==第二東海自動車道==名古屋南JCT==伊勢湾岸自動車道==四日市JCT==新名神高速道路=====16:30広島

徳島から広島に

徳島駅から特急うずしお(ジーゼルカー)

徳島での仕事は思いのほか早く終わった
今回はメンバーなので取りまとめ役は無いので気が楽だ
少し早い便に予約を変更するが。1時間に1本の特急は出たばかり・・・徳島駅で1時間ほど時間をつぶす
今回は予約はe5489でチケットレスで予約していたが、徳島駅ではICカードは使えない、仕方がないので発券したら、予約変更前の特急券が発行されていた、しばらく気が付かなかったが、席がブッキングしていて気付いた・・・2重購入になっていたので、車掌さんに説明して払い戻しにはできるようになったが、広島のみどりの窓口では1時間以上待たなくてはいかないので、精算せずに帰宅

高知から徳島に

徳島駅の周辺を歩く

高知での仕事が終わり、徳島までは車で送ってもらった
公共交通機関だと、高松をまわっても3時間半はかかる
車だと2時間半ほど、早く徳島のホテルに到着できた
少し、駅の周辺を歩いてみるが、食にの良さそうなところはないので、コンビニで購入となる

墓参り

墓を掃除して花を入れて・・・暑い
週末からのキャンプ道具を詰め込み

内部監査支援システムの構築

LLM(AI)に対するセキュリティ対策

AIに監査の内容を検討依頼するにはセキュリティの観点から、固有名詞等は排除しなくてはならない
固有名詞辞書を作成して、入力後チェックが行われるようにするが、まだ色々と誤検知が多いので修正

  • 工種辞書(一般的な工事種別のストップワード化)、建設業の一般工種は固有名ではない。stopwordsに追加:PC杭打工事, 杭打工事, 杭工事, 土工事, 鉄筋工事, 型枠工事, 躯体工事, 仮設工事・・・・
  • 関係節ガード:名前部分に連体修飾の接続語が含まれる場合は名称でなく説明文なので検出しないに関する|に係る|を伴う|における|についての|に対する(例:「騒音に関する工事」「振動を伴う工事」は非検出)
  • 接頭辞の反復剥がし:検出語の先頭から以下を繰り返し除去し、残りが工種辞書・stopwordsに一致すれば非検出とする(例:「各工区の土工事」→「各」除去→「工区の」除去→「土工事」=工種辞書→非検出)
パターン照合には原理的な精度限界があるため、確度に応じて扱いを分ける:
  • ブロック級(修正しないと先に進めない。従来通り):
  • 会社形態(株式会社/㈱等)、敬称付き人名(〜さん/氏/様)、識別子(認証番号等)、動的辞書・user_stopwords外のラベル由来一致
  • 注意級(黄色ハイライト+「固有名の可能性。問題なければそのまま進めます」。
    クリック不要で続行可能):
    工事名catch-all、作業所/建物、地名系(市/川/駅等)、役職付き人名、部署系

ハイライト色を分け(赤=ブロック級、黄=注意級)、注意級のみの場合は次へ進むボタンを有効のままとする。metrics.jsonlに「注意級を残したまま進んだ件数」を記録(実運用での注意級の妥当性評価用)。
v1.1の「一般名称として許可」ボタンは両級で引き続き有効。

待ち時間UX(API呼び出し中の表示)

全API呼び出し(/api/clarify, /api/factdraft, /api/candidates, /api/generate)に:

  • ボタンを即時無効化+スピナー表示(二重送信防止)
  • 段階メッセージを表示: 例
    candidates: 「類似事例を検索しています…」→(API送信後)「条項を判定しています…」
    factdraft: 「事実文を作成しています…」
    generate: 「指摘文案を作成しています…」
  • 経過秒数を小さく表示(「(12秒)」)
  • 可能なら /api/generate と api/factdraft はストリーミング応答(SSE)で文章を逐次表示する。実装が重い場合はスピナー+段階メッセージまでで可(その場合はREADMEに今後の課題として記載)
  • タイムアウト(120秒)時は再試行ボタンを表示

ひろしまみなとマルシェに 内部監査支援システム開発

朝は元宇品に散歩に行き、帰りにひろしまみなとマルシェに寄ってみる・・・炎天下の下、出店している人たちには脱帽ものです・・やはりお客は少なく営業的には苦しい・・・よしろう農園でしばらく雑談して帰宅、シャワーを浴びたらもう昼食
帰って月下美人を見ると昨晩に咲いていた・・残念見ることができなかった

ひろしまみなとマルシェでVFKさんとキク

内部監査支援システム開発

内部監査の指摘では、監査員の力量に左右されて的確な条項に基づく指摘が出来ていないのが実情である・・・今回、力量の不足を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から叩く検証ができる

月下美人とエスティマ整備

4年ぶりに月下美人の花が咲きそう・・冬に枯らしてしまってから、初めて復活

キクを散歩させて、眼医者に行き、青崎で気になっていたパン屋でモーニングを頂き、エスティマのオイル交換をする・・・7月末の信州旅行の準備

エスティマのオイル交換をする

YouTubeのお勧め画面に、フランク・チャックフィールドの引潮があり、久しぶりにクリックして視聴、波の音とカモメの鳴き声、そして聞きなれたメロディ・・この曲は、中学1年の時に、父が初めてビクターのステレオを購入したとき、おまけで付いていたサンプルレコードに収録されていた曲、はじめて水主町にあった我が家でステレオを味わった

▶この続きを見る・・・・

Jeepの車検

甲斐犬のキク・・タヌキ?と遭遇
J58 Jeepの車検 今年も無事に終わりました

今朝も暑い、キクを連れて元宇品を散歩、キクはタヌキを見つける・・・走りすぎてバテてました・・・午前中に、J58の車検に、無事に終わって、今回はブレーキオイルを入れ替えたので¥5万程、昼からNGIさんが訪ねて来て久しぶりに雑談

会社概要登録画面を刷新
マネジメントシステム登録画面をモーダル化
▶この続きを見る・・・・

日赤の定期診断 CodeX(GPT-5.6 Sol)

今日は3か月ごとの定期診断と栄養指導で、広島日赤病院に朝から、血液を採取して診断、前回は血糖値が悪かったが、今回は改善していた・・夕食を減らして、体重を2㎏程減量した効果が出たようだが、クレアチンは少し高くなっていた・・まあ、ほとんど体調は変更なしということか

日赤での定期診断 病院にスターバックスがある  血糖値が改善した

帰ってから、ログイン画面から会社概要への遷移が気に入らなかったので、修正して、会社概要ページを大幅に修正する・・ここに内部監査の計画及び実施状況をまとめる予定で、スペースを開けておく

会社概要のページを変更

Claude Fable5の試用期間が20日まで再び延長となった・・・OpenAIのGPT5.6のリリースで競争が激しくなった結果のようだ・・・GPT5.6はSol / Terra / Lunaのクラスがあり、Solは、Claude Fable5と同じ性能のようだ、GPT5.6のCodexはコーディング作業を支援する製品・エージェントという位置づけが明確になり、Claude Codeのプラグインとして使用できる
Claude Code(要件整理、設計、実装、リファクタリング)
Codex(セキュリティレビュー、バグ検出、性能改善)
さっそくClaude CodeにcodeX 5.6 solをプラグインで使えるように、指示してインストールを任せて、それと同時にChatGPTを無料版からPlusの有料版に切り替え、Claude CodeへのCodeXプラグインの設定は、便利なのもので調べる必要はなくすべてClaude Codeが以下のように実施してくれる

  1. Codex CLI更新: 0.130.0 → 0.144.4(GPT-5.6対応版)
  2. config.toml設定: C:\Users\syste.codex\config.toml の先頭に2行追記、model = “gpt-5.6-sol”、model_reasoning_effort = “medium”
  3. 既存の設定(プラグイン・trust設定)は無変更です
  4. 動作確認: テスト実行でヘッダーに model: gpt-5.6-sol / OpenAI Codex v0.144.4 を確認し、正常に応答が返りました

Claude Codeのcodexプラグインはモデル未指定時にconfig.tomlのデフォルトを使うため、今後 /codex:rescue やレビュー依頼はすべてSolで実行されます。推論の深さを変えたい場合は model_reasoning_effort を low / high に変更できます。

/codex:rescueメインの依頼コマンド。調査・修正・実装タスクをCodex(GPT-5.6 Sol)に委譲
/codex:review現在の変更をCodexにレビューさせる
/codex:adversarial-reviewより厳しい敵対的レビュー
/codex:status実行中ジョブの状況確認
/codex:resultバックグラウンドジョブの結果取得
/codex:cancel実行中ジョブの中止
/codex:setupCLI接続確認・設定

普段使いは /codex:rescue に続けて依頼内容を書くのが基本です。例:/codex:rescue 工程表の印刷でヘッダーがずれる原因を調査して
また、コマンドを打たなくても、会話の中で「これはCodexに調査させて」「Codexで直して」と指示してもらえれば、こちらからCodexエージェントを起動して結果を報告します。どちらでも同じSolが使われます

キクと散歩 工事一覧の変更

体が少し重い 今日はみなと公園で軽くキクを散歩させる

システムログインでは、最初に会社概要に遷移し、工事一覧と進んでいたが、最初に工事一覧へ遷移するように切り替え、工事一覧のデザインを変更して、工事のサムネイルが表示されるようにした・・・バタバタと変更するが、じっくり見るとボタンの配置が雑多なので、少し変更することにする

  • 2026年8月
     12
    3456789
    10111213141516
    17181920212223
    24252627282930
    31