開発中の樋門AIエージェントを、社員と共に育てる技術資産へ
樋門業務を支援するAIエージェントの試用一式を作ると、必要な知識が足りず「スカスカ」だと感じました。社員指導ナレッジと実案件での試用をつなぎ、改善を会社の共通版へ戻す構想と、まだ確認できていないことを整理します。
ここ数か月、日中の通常業務を続けながら、仕事の合間や夜間の時間を使って、樋門の業務を支援するAIエージェントを少しずつ開発しています。特定の計算だけを自動化するのではなく、元請会社から受け取った資料や条件を確認し、適用する基準を探し、計算書、図面、数量の関係までたどれるようにしたいと考えてきました。
将来的には、受注後の流れを理解したうえで、設計計画、設計条件の設定、構造計算、問題点の整理と元請会社への共有、その先の図面や数量まで、一連の業務を支援できるところを目指しています。
仕事を受けたとき、まず何を確かめるか。資料の版はそろっているか。設計条件が不足していないか。構造計算の前提と図面の形は合っているか。数量はどの寸法や本数を根拠にしているか。個々の作業をつなぎながら、一連の仕事を支援できるところまで育てたいのです。
もちろん、成果として使うものは人が確認します。根拠が足りないときはAIが無理に決めず、確認すべき点を人へ戻す。その役割分担は変わりません。
最近、このエージェントを社員にも使ってもらおうと、試用一式を作りました。ところが出来上がったものを見て、思わず「スカスカだな」と感じました。ここから、完成品を配ることより大事なことが見えてきました。
図面読解から、社員と試す段階へ
AIが樋門の配筋図を形として読み、別の図面や数量と結び付ける難しさは、以前の配筋図の読解を試した記事にも書きました。図面上の線を別の位置の寸法へ誤って結び付けることがあり、人が読み方を一つずつ説明してきました。
その課題は今も残っています。一方で、配筋図を題材に確認を重ねる中で、読み違いの可能性や、図面と数量の関係について確認すべき点を整理できる場面も出てきました。完成まで私一人で育てるより、そろそろ社員にも実際の仕事で試してもらった方がよいのではないか。そう考えるようになりました。
私だけが相手をしている間は、私が気づいた誤読しか直せません。実務で図面を読む社員が使えば、説明の足りない箇所や、私が当然と思って省いた前提も見えるはずです。今回の焦点は、図面を読む難しさそのものより、そこまで育てたエージェントを誰と、どう確かめていくかです。
社員側にも、試せる条件ができてきた
全社員へChatGPT Businessを広げた理由は、以前の記事に書きました。導入からまだ一月余りですが、現在は私を含め、全員がほぼ毎日のようにAIを使っています。文章を作るだけでなく、調べる、考えを整理する、Workへ仕事を渡して結果を確かめる、といった使い方も増えてきました。
パーソル総合研究所の2026年7月発表の調査では、正規雇用者の生成AI業務利用率は同年5月時点で54.3％、週4日以上使う「ヘビーユーザー」は21.1％でした。AIを仕事で使うこと自体は珍しくなくなりつつあります。私が気にしているのは利用頻度そのものより、社員が自分の仕事に合わせて使い、開発途中のエージェントにも改善を返せるかどうかです。
私が毎回「この操作をしなさい」と教えなくても、それぞれが担当する仕事の中で使いどころを探しています。AIへ仕事を渡して終わりではなく、返ってきたものを読み、足りない条件を伝え、もう一度確かめる。少しずつですが、「質問する相手」から「一緒に仕事を進める道具」へ変わってきました。
一人は、自分がAIへ入力しやすくするための補助アプリをPythonなどで作り、操作マニュアルまで用意しました。まだ他の社員へ広げた段階ではありません。それでも、用意された道具を使うだけでなく、自分の仕事に合わせて道具を作り始めたことには驚きました。
エージェントを社員へ渡すことを考え始めたのは、エージェントが完成に近づいたからだけではありません。社員も、AIを使いながら自分の仕事を見直し、必要なものを作るところまで来ています。使う側から改善を返してもらえる可能性が、以前より現実的になりました。
先日、「今の環境からChatGPTをなくしたら困る？」と聞くと、全員が「困る」と答えました。利用回数を測った結果ではありませんが、少なくとも社員自身の仕事に入り始めていることは感じます。開発途中のエージェントを社員と試す土台も、少しずつできてきました。
だからといって、全員が樋門エージェントをすぐ使いこなせると言いたいわけではありません。日々AIを使っていることと、図面や数量の根拠を追えることは別です。その差も含めて、実案件で確かめる必要があります。
前日の条件と、その日のExcelをDotがつないだ
同じ頃、その先を考えるきっかけになる出来事もありました。元請会社で概算工事費を算定する前日、ある業務のコンクリートについて、高炉セメントB種から普通ポルトランドセメントへ設計条件を変更する話をしていました。
その翌日、社員一人と元請会社へ行き、概算工事費を算定するため、積算ソフトで単価を約3時間整理しました。普通ポルトランドセメントの選択肢をすぐに見つけられず、時間も限られていたため、今回の概算には高炉B種の単価を参考にしました。数量計算書の設計条件を戻したわけではありません。設計上のセメント種別と、概算で参照した単価条件を分けたのです。
出来上がったExcelなどを自社の共有Driveへ保存し、元請会社を出ました。帰りの車でDotからメッセージが届きました。前日に話した普通ポルトランドセメントへの変更と、その日の積算に残る高炉セメントの違いを拾い、確認してきたのです。この確認を個別に頼んだわけではありません。
元請会社のパソコン画面をDotに見せていたわけでもありません。私がしたのは、作業後のExcelなどを共有Driveへ保存したことです。それだけに、前日の話と新しい資料を結び付けて確認が戻ってきたことには、少し驚きました。
「今回は普通ポルトランドセメントを選べなかったので、概算用の参考単価として高炉B種を使った」と返すと、Dotは単純な変更漏れとして扱わず、両者を分けて記録する方向へ整理しました。
驚いたのは、AIがミスを見つけたことではありません。今回は意図的に条件を分けています。前日の話と新しい成果物の違いにAIが気づき、決めつけずに人へ確認したことが印象に残りました。ただし、DotがDrive上のファイル追加をどのような内部処理で認識したのかまでは分かりません。また、この動きが樋門エージェントでも再現できたわけではありません。
もし「前日に普通ポルトランドセメントと決めたのに、Excelは高炉B種だから修正」と機械的に扱われていたら、今回の意図は消えてしまいます。違いを見つける、人に尋ねる、理由を聞く。そのうえで、設計条件と概算用の参考単価を別のものとして残す。この順番に意味がありました。
設計の仕事では、前と違うことがそのまま誤りとは限りません。元請会社からの条件、図面、数量、概算の間に違いがあれば、まず理由を確認し、意図的な扱いならその経緯を残す。樋門エージェントにも、そうした仕事の連続性を持たせたいと思いました。
一つの条件を変えると、数量計算書、図面表記、構造計算、概算工事費、条件一覧のどこに影響するのかも確認しなければなりません。個別の数字を正しく読む能力に加え、「前日に何を考え、その日に何を作ったか」をたどる力が必要なのだと、今回の出来事で実感しました。
こうした仕組みは、今回初めて思いついたものではありません。以前から、社員とAIが同じ会社の知識を使い、仕事で得た経験を再び会社へ戻す形を目指していました。技術ノートで書いてきた人とAIの仕事の分け方、エージェントの役割と道具、会社の記憶、社員自身の経験は、その一つの構想を成り立たせる要素です。
今回、樋門エージェントを社員と共有しようとして、その構想を実案件でどう試すかが具体的になってきました。ただし、社員とAIが使い、改善を会社へ戻す循環はまだ実務で回り切っていません。これから確かめる段階です。
社員指導の記録を、エージェントにも使えるか
この考えは、以前から続けてきた社員指導の記録ともつながります。当社では必要に応じて技術指導を録音し、文字起こしして、後から探せるナレッジへ整理してきました。社員指導から整理したナレッジが300件を超えたときにも書いたように、これは録音の本数ではなく、参照する価値がある内容を整理した件数です。
指導の場では、作業手順だけでなく「なぜその条件を見るのか」「どこに違和感を持ったか」「基準のどの部分をどう読んだか」まで話します。最初は、会話を録音しておけば後から使えると思っていました。でも、音声が増えるだけでは、必要な場面で見つけられません。文字起こしし、作業内容や論点を整理し、索引から探せるようにして、ようやく次の仕事で使える形に近づきました。
そこには「平面図だけで形状を決めない」「数量が合っても寸法の根拠を確認する」「過去案件とは条件が違う」といった、完成した成果物だけでは見えにくい判断が含まれています。これまでは主に社員が振り返るための知識でした。今回、それをエージェントにも参照させ、確認すべき場所を探す手掛かりにできないかと考えています。
過去の記録を今回の正解として使うつもりはありません。案件の条件も、基準の版も違います。何を参照させ、適用できる範囲と出典をどう確かめるかは、これから検証することです。
たとえば過去に「この形状は平面図だけで決めない」と残っていれば、エージェントは今回の図面でも断面図を探すきっかけにできます。ただし、過去の形状や寸法をそのまま今回へ当てはめてはいけません。会社の記憶は正解集ではなく、確認の入口として使わせたいと思います。
そして、会社の知識をAIへ渡すだけでは終わりません。社員とAIが実案件で使えば、「この説明では分からない」「この資料も必要だった」「今回の条件には使えなかった」という結果が出ます。それを確認し、会社の知識へ戻せるようにしたいのです。
これまでは、私や経験者が社員へ説明し、その内容を記録して次の社員へ渡す流れが中心でした。今度は社員自身が使って気づいた不足も戻ってきます。社員とAIが同じ記録を参考にし、実務で確かめ、必要なら記録そのものを直す。ここまでつながれば、指導の記録とエージェント開発は別々の取り組みではなくなります。
試用一式が「スカスカ」に見えた理由
樋門エージェントを社員へ渡そうと、最初に試用一式をZIPにまとめました。Markdownの説明や小さな検算教材は入っていました。しかし、数か月かけて少しずつやり取りし、試してきた内容と比べると、仕事を進めるための中身が足りませんでした。
社員がそれを開いたとき、まず検算教材には取り組めるかもしれません。でも、実際の業務を受けたら、その前に確かめることがたくさんあります。元請会社から何を受け取り、何が不足しているか。資料の間で条件が食い違うときは、どれを正として進めてよいのか。自分たちで判断してよい範囲はどこまでか。教材だけでは、その入口に立てません。
どの資料が最新版か。どの基準を見るか。元請会社から受けた条件をどう整理するか。計算と図面、数量をどう結びつけるか。根拠が足りないとき、どこで確認を返すか。私が共有したかったのは、配筋図の小さな教材だけでなく、こうした仕事の進め方全体でした。
「スカスカ」と感じたのは、教材の量が少なかったからだけではありません。育ててきたエージェントの一部分を切り出して、全体を渡したつもりになっていたからです。ここを直さなければ、社員に使ってもらっても、開発中に見えてきた課題を同じ土台で考えられません。
最初の一式が無駄だったわけではありません。小さな教材で動作を確かめる役目はあります。ただ、私が求めているのは教材を順番に解くAIではなく、仕事の資料を見て、必要な確認を選び、根拠が足りなければ止まれるエージェントです。配布物を見て感じた違和感が、共有する対象を考え直すきっかけになりました。
改善を会社の共通版へ戻す
そこで、GitHubを使えないかと考えています。ファイルの変更履歴を残し、複数人で修正案を確認できるサービスです。ZIPを配るだけなら簡単です。しかし社員ごとに手順や指示を直していけば、すぐに別々のエージェントになります。何を、なぜ変えたか。どの条件で使えるか。どの状態を共通版にするか。その履歴を追い、改善案を確認して戻せる形が必要です。
ある社員が「この説明では図面の位置が分からない」と直し、別の社員が「この数量表も参照したい」と直す。どちらも改善かもしれません。しかし、各自の手元だけで変更すると、次に誰がどの版を使えばよいのか分からなくなります。逆に一つの共通版へ何でも入れれば、ある案件だけで成り立つ例外まで一般ルールになってしまいます。変更理由と適用条件を一緒に残し、人が確認して共通化する必要があります。
図面や計算書などの原本は、社内の共有ストレージであるNASで管理します。共有Driveはバックアップとして併用し、AIへ資料を渡す際にも活用します。そのうえで、判断の記録や読み方はMarkdownに整理する。エージェントへの指示、コード、テスト、変更理由はGitHubで管理する。今は、そんな役割分担を考えています。運用として機能するかは、社員に試してもらって確かめます。
GitHubを使えば自動的に会社の資産になる、とも考えていません。原本への参照が切れていないか、提案された修正に根拠があるか、案件固有の扱いを一般化していないか。共通版へ取り込む前の確認は残ります。管理したいのはファイルの数ではなく、社員とAIが同じ土台で仕事をし、直した理由まで後からたどれる状態です。
最初は社員一人と、数量が分かっている実案件で試すつもりです。必要な資料へたどり着けるか。図面と数量の関係を説明できるか。過去の記録を適切に参照できるか。分からないとき、人へ確認を戻せるか。そして、社員の実務を本当に助けられるかを見ます。まず一人で問題を見つけて直しますが、目指すのは全社員が同じ共通版を使い、それぞれの経験を戻せる状態です。
数量が分かっている案件なら、エージェントが出した説明を既存の成果や元資料と突き合わせられます。答えが合っているかだけでなく、どの図面を根拠にしたか、途中で誤読したときに気づけるか、確認を返すべき場面で止まれたかを見たいのです。一人目で見つかった不足を直し、別の経験を持つ社員にも使ってもらえば、私一人では見落としていた問題も出てくると思います。
社員自身が得た経験も、会社へ戻したい
これまでの社員指導ナレッジは、どうしても私から社員へ伝えた内容が中心でした。しかし、社員がAIと毎日仕事をすれば、社員自身の経験も生まれます。「こう聞いたら資料へたどり着けた」「この条件ではAIが間違えた」「この小さな道具を作ると作業が進んだ」。そうした発見を本人のチャット履歴だけに置いておくのは、もったいないと思います。
入力補助アプリを作った社員の経験も、その一つです。今は本人が使いやすくなった段階でも、どこに困り、何を作り、実際に使ってどうだったかが残れば、他の社員が似た困りごとに出会ったときの手掛かりになります。うまくいかなかったことも、次の修正につながります。
代表や経験者から社員へ知識を渡す流れに、社員がAIと仕事をして得た経験を会社へ戻す流れを加えたい。その両方をエージェントの改善にも使えれば、会社の知識は一方向ではなくなります。
社員自身がAIと仕事をする中で見つけた使い方、間違い、足りなかった資料も、共通版へ戻す材料になります。先に触れた調査では、AIと仕事をする際の力の一つを「蓄える（組織知の更新）」と呼んでいます。私がやりたいことも、一回の便利さをそこで終わらせず、次の社員と次の仕事で使えるようにすることです。
樋門エージェントはまだ完成していません。社員指導の300件超のナレッジも、全部をそのままAIへ渡せばよいわけではありません。まず実案件で使い、何が足りないかを確かめ、人が根拠と適用範囲を確認して直す。その結果を共通の知識、手順、コードへ戻し、また社員とAIが使う。エージェントだけでなく、この循環まで会社の技術資産にできるか。今は、その試行の入口にいます。