半年前に建築図面をAIへ読ませたときは、AIが処理しやすい形を人間が先回りして用意していた。今回はそこから進んで、資料の同期、候補の抽出、人の確認、Excel出力を専用の業務画面から扱えるようにした。
変わったのはモデルだけではない。ハーネスやループの知見がたまり、人間の組織に近い仕事の受け渡しを、状態と画面を持つワークフローとして組めるようになった。
半年前は処理をコードでつないでいた
最初の構成では、OCRにGemini APIを使い、Pythonでモデルへ渡すデータを整形していた。Excelへの直接記帳は信頼性に欠けたため、抽出結果をいったんJSONへ保存し、別の処理でExcelへ反映した。
図面を読む処理、データを整える処理、Excelへ戻す処理を一つずつ接続する必要があった。AIが失敗しにくいように、人が仕事を細かなプログラムへ分解していた。
その後、ChatGPT DesktopでPDFとExcelを直接扱い、業務固有の手順を SKILL.md に置く構成へ変えた。専用のOCR処理や中間JSONは減り、依頼用フォルダもGitで管理できるようになった。確認作業はコンテキストを分けたエージェントへ渡せるため、一つの会話のまま自己確認させるよりも安定する。
ただし、入口はまだチャットだった。依頼文を考え、会話から現在の状態を読み取り、次に何をすべきか判断する必要がある。AIが仕事を実行できても、利用者にとって扱いやすい業務フローにはなっていなかった。
チャットの前に業務画面を置く
現在はConstruction AI Platformのダッシュボードから案件を選び、Driveの同期、候補抽出、確認、Excel出力を進める。
担当者
↓
ChatGPT Sitesのダッシュボード
↓
Cloudflare D1のジョブ
↓
Local Bridge → Codex App Server → Google Drive
↓
候補・根拠画像 → 担当者が修正・承認
↓
デモ用Excel → Drive「03_AI加工物」
ChatGPT Sitesが画面と状態を持ち、ローカルBridgeが待機中のジョブを取得する。BridgeはCodex App Serverを通してDriveの資料を読み、結果をダッシュボードへ戻す。利用者にはコマンドやスレッドを見せず、「同期する」「候補を確認する」「Excelを作る」という業務上の操作だけを出している。
要件を大まかに渡した段階でも、ChatGPT Sitesは候補を確認するための画面をかなり自然に組み立てた。AIに仕事をさせるだけでなく、その出力を人が判断するUIまで同じ流れで作れるようになったことが、今回いちばん大きな変化だった。
正本と処理状態を混ぜない
顧客から受け取った図面や指示書はGoogle Driveを正本とし、AIは 01_受領原本 を変更しない。案件、候補、承認状態、監査履歴はCloudflare D1、PDFから切り出した根拠画像はCloudflare R2へ置く。Gitには業務ルール、スキーマ、Bridge、テストを置き、顧客資料は入れない。
候補には資料ID、改訂、ページ、引用、位置を残す。図面PDFでは根拠箇所の座標も保持し、該当部分を画像として候補と並べる。読めない内容は推測で埋めず、候補は確認待ちから始める。
担当者が候補を修正するときは、古い画面から新しい値を上書きしないようにバージョンを確認する。ジョブが途中で止まった場合はleaseの期限後に再取得し、同じ処理で成果物を重複して作らないようにする。ハーネスで書いていた作法を、画面、状態遷移、テストで機械的に守る形へ移した。
まだ自動化していない判断を残す
現在動いているのは、Driveの同期、候補抽出、根拠画像の生成、人による修正と承認、確認済み候補からのデモ用Excel出力までである。独立したレビューエージェントと、重大な指摘・人の承認を組み合わせた正式公開ゲートはまだ接続していない。
そのため、生成したExcelは 03_AI加工物 に保存し、正式成果物用の 04_承認済み成果物 へは送らない。できていない確認をUIの言葉だけで済ませず、保存先と状態遷移でも越えられないようにしている。
半年前に作っていたのは、図面を読むための処理だった。今作っているのは、AIの候補を人の仕事へ渡し、判断の結果を次の処理へつなぐための基盤である。モデルへの指示だけでなく、正本、状態、根拠、確認者、失敗からの再開まで含めて設計することで、AIを業務の中へ置けるようになってきた。