> ~/hayashigoto/logs/zumennya-design.md

図面屋さん（ずめんや）は、GrokBot 5体と人（承認者）で、建築の内装図面から仕上げ一覧を作るチームです。仕上げ一覧は、どの部屋の、どの面に、どの仕上げ材と品番を使うかをまとめた表です。2026年10月のGrok Bot Tokyo Hackathonに出しました。

考え方は一つで、作業はbotがし、決めるのは人です。そのための決まりをどこに置いたかを、事例としてまとめておきます。

5体に役割を分けた

5体は同じグループチャットにいて、役割を分けて動きます。

• ひろいだし：図面を読み、部屋・部位・仕上げ・品番の候補を、根拠画像つきで登録します。読めない値は推測せず「要確認」にします。
• かたろぐ：建材カタログを版ごとに登録し、候補の品番を照合します。「一致」にするのは品番が文字どおり同じときだけで、名前が似ているだけでは確定しません。
• かくにん：候補を、原本の図面と根拠画像だけで確かめ、重大か軽微の指摘を出します。直った版を確かめて、指摘を閉じます。
• おやかた：人との窓口です。人に判断を聞き、返事どおりに判定を記録します。
• かきだし：全件が決まったら、最終版をGoogleスプレッドシートとExcelファイルに書き出し、読み直して記録と突き合わせます。

それぞれの手順は、botごとのSkillに書いています。

人に聞くのは、レビューのあとに一度だけ

人に聞くのは、レビューが済んでからの1回にまとめています。おやかたが番号つきで、選択肢とおすすめ、根拠を見られる画面へのリンクを添えて聞き、人はチャットで答えます。人が選んだ値は、まず候補の新しい版として入れ、その版を承認します。

公開デモの架空の案件「こもれび診療所」では、候補26件のうち、読めない値や図面どうしの食い違いなど7件は、人が値を選びました。

画面は、見るためだけにした

記録を見る画面「図面帳」は、案件の一覧と、案件ごとの看板の2つだけです。看板の列は「いま誰の番か」で分けています。

カードを人が動かす操作はありません。botが記録を足すと状態が決まり、カードの列が変わります。たとえば、まだ判定も保留もない候補に、かくにんが重大な指摘を出すと「ボットの番」に戻ります。直した版でその指摘が閉じると、ほかに止めるものがなければ「あなたの番」に進みます。

案件をまたいだ調べもの、たとえば品番がどの案件で使われているかは、画面を増やさず、おやかたに聞きます。根拠を見比べるのは画面で、決めるのはチャットで、という分け方です。

決まりは、DBに守らせる

承認の決まりは、botの手順やAPIのコードではなく、DB（Cloudflare D1）のトリガーと制約に置いています。APIの作りが変わっても、DBが通しません。

• 判定は、候補の最新の版に対してだけできます。版が変わると、前の版への承認は引き継ぎません。
• 「要確認」の版、重大な指摘が開いている候補、保留中の候補、かくにんが一度も見ていない候補は、承認できません。
• 書き出しを「最終版」として記録できるのは、候補が1件以上あり、すべての候補が承認か対象外になり、保留と重大な指摘がなくなり、読み直しの結果が一致したときだけです。
• 記録は追記だけで、直すことも消すこともできません。例外は、根拠画像をあとから1回だけ足すことと、廃番や使用終了の印を付けることだけです。直すときは、新しい版や、指摘を閉じる行、保留を解除する行を足します。

botが手順を間違えても、決まりに合わない記録はDBで止まります。

原本は、Driveに置いたまま

図面やカタログの原本はGoogle Driveに置いたままで、botは読むだけで変更しません。Driveに書くのは、書き出した仕上げ一覧だけです。

アプリはTypeScriptとHonoで書き、Cloudflare Workersで動かしています。botが記録を書き込めるのはこのアプリのAPIだけで、DBを直接さわる鍵は使いません。

割り切っていること

• 鍵は全botで1つで、どのbotかは申告です。役割ごとの書ける範囲は書き間違いを防ぐためのもので、本人確認ではありません。
• 人の判定は、チャットで受けた返事を、おやかたが名前つきで記録します。本人確認はしておらず、画面にもそう出します。
• 直した版をもう一度レビューするかは、おやかたの判断に任せ、DBでは止めていません。

公開デモでは、こもれび診療所を図面の登録から最終版の書き出しまで通した記録を見られます。ログインは不要で、中身はすべて架空のデータです。