社員と使い始めた樋門AIエージェントで、共有し切れていない判断が見えてきた
樋門AIエージェントをGitHubで社員と共有し、実務で使い始めました。ハンチ筋の寸法計算で、以前確認してきた鉄筋径の扱いとの違いが見つかり、説明の不足が表面化。Codexで判断の根拠や条件を精査し、共通版への追加を続けています。
10月9日の技術ノートでは、開発中の樋門AIエージェントを社員と共有し、実務で見つかった不足を会社の共通版へ戻していきたいと書きました。その後、GitHubのリポジトリを社員と共有し、実際の業務で使ってもらう段階へ進みました。GitHubは、プログラムや文書を変更履歴とともに管理し、共有するために使っているサービスです。リポジトリは、それらのファイルと履歴をまとめて管理する場所です。
前の記事を書いた時点では、まず試せる状態をつくり、社員に渡すことが課題でした。今回は、渡した後に見えてきたことです。私がAIとのやり取りで積み重ねてきた判断の細部が、共有した知識へ十分に移せていませんでした。
私の手元で使っているときには、過去の経緯を知っている私が、その場で説明を補えます。しかし、社員が使うときには、共有された説明が手掛かりになります。実務で使ってもらったことで、私が補っていた前提のうち、何を共通版へ残せていなかったのかを、具体的に見直すことになりました。
ハンチ筋の寸法計算で、以前のやり取りとの違いが出た
きっかけの一つが、社員がハンチ筋の寸法を求めていたときのことです。これまで私は、鉄筋の呼び径を使って、AIエージェントと確認を重ねてきました。ところが、社員が共有版を使って寸法を求める場面では、公称直径を使った計算になっていました。
以前から私とAIが確認してきた扱いと、社員が使ったときの扱いが違っていたのです。そこで社員が、なぜ公称直径を使う話になったのか、その寸法の出し方がGitHubで共有した内容に書かれているのかを確認しました。この問いかけから、共有している知識を見直す話が始まりました。
私としては、呼び径を使う話は、AIとのやり取りで何度も扱ってきた内容でした。それだけに、社員が使う場面で別の扱いが出てきたことは、共有できたつもりの内容を確かめ直すきっかけになりました。
確認を進める中で、GitHubに残した説明では、細かな判断を支える内容がまだ足りていないと感じました。私とAIの間では繰り返し確認してきたことも、その根拠や条件まで、社員が使う共有版へ十分に移せていなかったのだと思います。
ここで、呼び径と公称直径のどちらかを、あらゆる寸法計算で使うべきだと言いたいわけではありません。この記事で残したいのは、今回、呼び径を使って確認してきた経緯があり、それが社員の使う環境では十分に伝わっていなかったという経験です。実際の検討では、何の寸法を求めるのか、適用する基準や資料、対象となる条件を確認する必要があります。
共有するファイルがそろった後も、実際の仕事で同じように判断を支えられるかは、使ってみなければ分からない部分がありました。今回は社員自身が違いに気づき、理由を尋ねてくれたことで、その不足が表に出ました。
私が補っていた前提は、社員には見えない
私がエージェントを使うときには、これまでの開発の経緯を知っています。過去にどこを読み違えたか、なぜその確認を加えたか、似た話をどこで扱ったか。AIの説明を読みながら、「この条件も必要だった」と気づき、その場で補うこともできます。
社員が共有されたリポジトリを開くときには、その経緯をすべて知っているわけではありません。そこに書かれた内容や参照先から、必要な前提を確かめることになります。説明が抜けていても、以前に私とAIが何を話していたかまでは分かりません。
この違いは、私だけで動作を確かめている間には、見落としやすかったのだと思います。作業が進んでいたとしても、その途中で私がどれだけ説明を補っていたかまでは、十分に意識できていませんでした。
GitHubを通じて使えるようにした段階では、私の手元で育ててきたエージェントと同じように判断を支えられるところまで、知識を渡し切れていませんでした。 ファイルを共有できたことで、その中に必要な説明も入ったつもりになっていなかったか。そこを見直す必要が出てきました。
これは、使った社員が過去の説明を知らなかったことで片づく話ではありません。初めてその場面を扱う人でも、必要な根拠や条件を確認できるようにすることが、共有する側の課題として見えてきました。
判断の根拠と、使える条件を一緒に残す
今回のような内容を共有するとき、結論だけを短く残せば、文書としては分かりやすく見えるかもしれません。しかし、前提が少し変わったときに、その結論をそのまま使ってよいかが分からなければ、実務では迷います。
ハンチ筋の寸法についても、何を確認するための計算なのか、どの資料や基準を参照するのか、今回の条件はどこまでなのかを追える必要があります。別の条件に出会ったときには、何を確かめ直し、どこから人へ確認を戻すのかまで分かる形にしたいと考えています。
過去の会話を一部取り出すだけでも、注意が必要です。その一節の前に確認していた条件が抜けると、限定された場面の説明が、広く使えるルールのように読めてしまうことがあります。保存した文章だけを読んでも、何についての説明か、どこまで適用できるかが分かるように整える必要があります。
当社は、元請会社から指示や条件を受けて、作業や照査、資料整理を進める立場です。根拠や条件がはっきりしないときには、AIの説明だけで確定せず、元請会社へ確認するための材料を整理することも必要になります。
エージェントに持たせたいのは、答えを出すための知識とともに、判断を保留し、確認へ戻すための手掛かりです。今回の経験から、そうした細部まで言語化する必要を、改めて感じました。
Codexで精査し、GitHubへの追加を続けている
不足が見えた後は、これまで積み重ねてきた内容を、改めてCodexで精査する作業を進めています。Codexは、OpenAIの開発作業を支援するAIエージェントです。今回、私が開発や文書の整理、共有する内容の更新を進めるために使っている環境でもあります。
私がAIと確認してきたことのうち、社員が使う際に必要な説明が抜けていないか。結論だけが残り、根拠や条件が省かれていないか。そうした点を見直し、GitHubへ追加・更新する作業を続けています。
この整理と共有版への反映も、実作業はCodexで進めています。エージェントを社員へ渡した後も、実務で見つかった不足を受けて、開発に使ってきた環境で共有内容を育て直しているところです。
追加する内容は相当な量になってきました。ただし、過去のやり取りをすべて整理し終えた段階ではありません。私の手元で積み重ねてきた判断と、社員が参照できる説明との間には、まだ埋めるべきところがあると考えています。
文書の量が増えたことだけでは、使えるようになったかは分かりません。必要な場面で説明へたどり着けるか、その説明から次の作業を進められるかは、更新した内容を実際に使う中で確かめていく必要があります。
配筋から、条件整理や報告書へ仕事をつなげる
樋門エージェントで扱いたい仕事は、配筋や数量の確認に限りません。適用する基準を探して読み、元請会社から受けた設計条件を整理し、資料の食い違いを確かめる。判断できないことは人へ確認し、検討の経緯や残った課題を報告書へまとめる。そうした一連の業務を支援できるようにしたいと考えています。
今回のハンチ筋の例でも、寸法を計算するところだけを見れば、小さな知識の不足に見えるかもしれません。しかし、その値を使った理由が後の記録に残らなければ、照査する人や、後から作業を引き継ぐ人は、根拠をたどれません。
図面と計算書で表現が違う場合も、単純な誤りなのか、目的に応じた使い分けなのかを確認する必要があります。その確認に必要な資料が分からなければ、計算方法だけを追加しても、仕事の途中でまた止まります。
そのため、共通版を見直すときには、個々の説明とともに、仕事の中での使いどころも残していきたいと思っています。どの段階で参照するのか、何を確認するのか、確認した結果を次の作業へどう渡すのか。そこがつながると、検討の経緯も残しやすくなると考えています。
これは、これから整えていきたい範囲です。今回、具体的な不足が見えたことをきっかけに、配筋の説明だけで終わらず、周辺の仕事にも目を向けて共有内容を見直していきたいと思っています。
社員が使った経験を、次の更新につなげる
社員から戻ってくるものは、完成した改善案でなくても構いません。「この説明では判断できなかった」「どの条件を使えばよいか分からなかった」という経験があれば、知識のどこを直すべきかを考えられます。困った場面と、そこまでに確認したことが分かれば、追加する説明も具体的になります。
今回も、社員が公称直径を使った計算の理由を尋ねたことが、見直しの入口になりました。使う人が疑問を持ち、その経緯を戻してくれたことで、私だけでは見えにくかった共有内容の不足を考え直せました。
その場の作業を進めるために私が補った説明も、共通版へ戻さなければ、次に使う人が同じところで止まるかもしれません。一方で、一つの案件で使った扱いを共通版へ加える際には、他の仕事にも当てはまるか、根拠と適用範囲を人が確認する必要があります。Codexが整理した内容についても、この確認は残ります。
GitHubで共有する意味も、こうした更新を通じて確かめていくことになります。どの説明を、なぜ追加したのか。何を確認できるようにするための変更なのか。その理由も一緒に残していきたいと思っています。
10月9日の記事から進んだのは、共有する構想が実務に入り、説明の不足を具体的に確かめ、共通版への追加を続ける段階になったことです。
社員が使い、分からなかった点を確かめ、Codexで内容を整理してGitHubへ戻す。そして、直した内容で次の確認を進められるかを、また実務で見る。その繰り返しを通じて、私が横から説明しなくても進められる範囲と、人へ確認を戻すべき範囲を、少しずつ明らかにしていきたいと思います。