半年前にも、建築図面をAIに読ませ、クロス仕様書の作成を自動化しようとした。
当時は、OCRにGemini APIを使い、AIが処理を再現できるようにPythonコードを含めたリポジトリを用意して、Claude Opus 4.5に実行させていた。Excelへの直接記帳は信頼性に欠けたため、まずJSONとして結果を出力し、別の処理でExcelへ反映する構成にした。
図面を読む処理、モデルへ渡すデータの整形、Excelへ戻す処理を一つずつ接続する必要があり、動かすだけでも多くの準備が必要だった。
今回、同じ仕事をあらためて組み直したところ、構成は大きく変わった。
専用の処理を作るところから、仕事の進め方を渡すところへ
現在は、ChatGPTのデスクトップアプリにExcelとPDFを扱うプラグインを入れ、リポジトリの SKILL.md に仕事の進め方を定義している。
利用者が行うのは、図面を渡してやってほしいことを伝えるところまでである。リポジトリ内には成果物の保存先となるフォルダを用意し、その構成ごとGitHubで管理している。「完成したファイルはここへ保存する」という指示も、Skillとフォルダ構成の一部として残る。図面の読み取り、候補の整理、確認、Excelへの記帳は、そこからSkillに記した手順と判断基準に沿って進む。
半年前の構成では、AIが失敗しにくいように人が処理を細かく分け、その間をコードでつないでいた。今回は、既存のファイル形式を扱う能力をプラグインに任せ、人は業務固有のルールと成果物の置き場所をSkillとリポジトリへ残している。
結果として今回のワークフローでは、OCR APIを呼ぶ処理、AI向けのPythonコード、JSONをExcelへ移すための別処理を用意せずに済んだ。モデルへ渡しているのも、処理の再現コードではなく、仕事を完了させるための文脈と制約に近い。
依頼から承認画面まで作られた
最初から細かな画面仕様を決めていたわけではない。必要なことを大まかに伝えただけだったが、AIは図面と抽出候補を見比べ、修正、採用、対象外を判断できる承認画面まで作った。
この画面では、AIの出力をそのまま正解として扱わない。候補はすべて確認待ちの状態から始まり、人が根拠となる図面と照合して確定する。未確認の項目が残っている間は、完成した仕様書として出力しない。
AIに任せる範囲が広がっても、最後の判断まで曖昧に委ねる必要はない。抽出する役割と承認する役割を分け、状態を画面に残すことで、作業の速さと確認可能性を両立できた。
確認はコンテキストの新しいサブエージェントへ渡す
生成した本人にそのまま確認させると、実装時の前提を引き継いだまま結果を見ることになる。そこで確認作業は、コンテキストが新しいサブエージェントへ渡す。
サブエージェントは、最初の判断や実装過程に引っ張られず、図面、抽出結果、Excelの出力をあらためて照合する。作業者とは別の目線を入れることで、同じエージェントが一度だけ自己確認するよりも、結果の確度を上げやすい。
これは、モデルを増やせば自動的に正しくなるという話ではない。何を確認し、どの状態なら完了とするかを先に定義し、検証する側には必要な証拠だけを渡す。役割と出口を分けることが重要になる。
人間の組織と同じように役割を組む
今回うまくいった背景には、個々のモデルの性能向上だけでなく、ハーネスや実行ループに関する知見が溜まってきたことがある。
仕事を一つの長い指示として投げるのではなく、実行する役割、承認する役割、別の視点から確認する役割へ分ける。途中の状態はファイルと画面に残し、次の担当が同じ成果物を参照できるようにする。曖昧な項目は推測で埋めず、人へ戻す。
これは、人間の組織で担当者、承認者、確認者を分けるワークフローに近い。違うのは、それぞれの役割、参照する証拠、完了条件を、Skillやコードとして同じリポジトリに置けることである。
半年前は、AIが実行しやすい処理へ仕事を変換することに多くの時間を使っていた。今は、仕事の進め方と確認の仕組みを整えれば、AI側が既存のPDFやExcelへ合わせて動ける。
図面認識の精度だけを上げる試みから、仕事を安全に受け渡し、確認し、完成させる環境を作る試みへ変わった。