AIがAIに仕事を頼む。dotからCodex Cloudへ、数量表チェックを任せてみた
dotからCodex Cloudへ開発タスクを任せ、合計プログラムと架空の数量表チェックを試しました。クラウドで動いた範囲と、GitHubへの成果の保存や実務資料での検証など残る課題を整理します。
前々回の技術ノートでは、Google Chatに残る仕事のやり取りをChatGPT側から探して確認できるようにしました。前回は、外出先からdotに社内ポータルの続きを頼み、調査や作業の準備を進めてもらいました。
社内ポータルの開発や確認には、会社のローカルPCを使っています。そこで次は、ローカルPCを使わずに完結できる小さな開発も試したいと考えました。
今回試したのが、dotから、クラウド上でコードの作成やテストを進めるCodex Cloudへ開発を依頼する流れです。ここに書くのは私の利用環境での体験であり、使える機能や設定は環境によって異なります。
私がdotに目的を伝え、dotがクラウド上の開発環境に作業を依頼する。そこでプログラムを作り、テストした結果を受け取る。言ってみれば、AIが別のAIに仕事を頼む仕組みです。
まずは簡単な合計プログラムで、この流れが動くことを確認しました。その後、土木設計の仕事に少し近づけて、架空の数量表を使った差分チェックも試しました。
今回は、その結果と、実務に使うためにこれから確認したいことを整理します。
dotからCodex Cloudに開発を依頼する
今回、私の利用環境では、保存済みのCodex Cloud環境を指定して、dotから開発タスクを依頼できることを確認しました。OpenAIの公式説明でも、設定済みのCodex Cloud環境をdotから利用できると案内されています。
なお、Codex Cloud自体は以前からあり、クラウド上でプログラムを作成・テストすることはできました。今回新しく試したのは、Codex Cloudの性能ではなく、dotからその開発環境へ直接タスクを依頼する仕組みです。従来のCodex Cloudでも同じプログラムは作れますが、普段の仕事を相談しているdotから開発を開始し、結果を受け取れる点が、私にとっての違いです。
Codexには、プログラムの作成や修正、テストなどを任せます。dotとは、何をしたいのか、どこまで任せるのか、結果をどう確認するのかを相談します。
今回の流れは、次のようなものでした。
- 私がdotに、試したい内容を伝える
- dotがCodex Cloudの環境を指定して開発を依頼する
- クラウド上でプログラムを作成し、テストする
- dotが結果を確認し、私に報告する
最初は環境が登録されておらず、実行できませんでした。クラウド環境を準備して指定した後、依頼と実行が通りました。
合計プログラムから、架空の数量表チェックへ
最初は簡単な合計プログラムで確認
初めに依頼したのは、簡単なPythonプログラムの作成とテストでした。
目的は、難しい計算をさせることよりも、dotから依頼した作業が、会社のローカルPCを使わずにクラウド上で完了するかを確かめることでした。
結果は次のとおりです。
| 項目 | 結果 |
|---|---|
| 実行環境 | Codex Cloud |
| OS | Debian Linux |
| Python | 3.12.14 |
| 1〜10の合計 | 55 |
| 0までの合計 | 0 |
| 不正な入力 | エラーとして処理 |
| 自動テスト | 10件すべて成功 |
| ローカルPCでの実行 | なし |
小さなプログラムではありますが、私がdotに依頼し、dotがCodex Cloudに開発を任せ、クラウド上で作成とテストが完了するところまで確認できました。
これで、開発を委任する最初の流れはつながりました。次に知りたくなったのは、この流れを土木設計の仕事に近い題材でも使えるかということです。
架空の数量表で差分チェックを試す
当社の本業は土木設計です。プログラムを作ることを、日々の確認作業の効率化や品質の確保につなげたいと考えています。
そこで次の題材に選んだのが、新旧数量表の差分チェックでした。
設計変更では、どの項目の数量が変わったのか、金額や集計結果に不一致がないかを確認する必要があります。変更箇所と計算結果を並べて見られれば、技術者が確認すべき場所を絞りやすくなります。
今回は実際の案件資料を使わず、AIが作成した架空の数量表で検証しました。意図的に変更や誤りを含め、その箇所を検出できるかを確かめる試験です。
| 確認した項目 | 今回の結果 |
|---|---|
| 新旧数量表の変更 | 8件を検出 |
| 明細金額の不一致 | 2件を検出 |
| 総計の不一致 | 2件を検出 |
| 境界条件などの自動テスト | 12件すべて成功 |
最初の合計プログラムの10件と、この数量表チェックの12件は、別の試験です。変更8件、明細金額不一致2件、総計不一致2件も、それぞれの確認項目の結果として記載しています。自動テストの12件は、これらの検出件数とは別の数値です。
今回の検証では、用意したデータに含まれる想定した変更や誤りを検出できました。単純な計算の動作確認から、実務の確認作業に近いところへ、一歩進めたと感じています。
ただし、ここは慎重に受け止める必要があります。
今回はAIが自ら作った、答えの分かっているデータでの試験です。未知の実務資料に含まれる誤りを、同じように漏れなく検出できると確認したわけではありません。
実際の数量表には、表の構成、項目名、単位、丸め方、集計範囲などに違いがあります。比較する行をどう対応づけるかによっても結果は変わります。こうした条件を整理し、人間が確認した結果と照らし合わせる検証が、今後必要になります。
GitHubとの連携はどこまで進んだか
今回の検証とあわせて、以前から考えていたGitHubとの接続と、非公開リポジトリの作成までは進めました。GitHubは、コードと変更履歴を保存・共有できるサービスです。
ただし、本稿執筆時点では、今回作ったプログラムなどの成果をGitHubへpushすることや、変更内容をレビューするためのプルリクエストを作ることは、まだ実施していません。
クラウド上でプログラムが動いたことと、その成果が履歴付きで保存され、後から確認できることは、分けて確かめたいと考えています。
実務で繰り返し使うなら、どのプログラムを使ったのか、どの変更を加えたのか、どのテストを通したのかをたどれることが重要です。次に進めたいのは、成果の保存、変更履歴の管理、内容のレビューまでを一連の流れとして試すことです。
dotからの依頼とCodex Cloudでの開発・テストは動きました。GitHubへの保存とレビューまで通せれば、ローカルPCを使わない小さな開発の成果を、後から確認できる形で残せます。CADや専用ソフト、社内環境が必要な処理は、引き続きローカルPCで扱います。
実務に使う前に、開発の進め方を整える
開発中の仕事は、そのまま継続する
現在進めているラボ、樋門エージェント、社内ポータルの開発は、これまでの環境を維持する方針です。
これらはすでに、ローカルPCを開発・確認作業の拠点として進んでいます。途中で環境を変えると、ファイルの場所、認証、使用ソフト、動作確認の方法などを改めて整理する必要が出てきます。
移行のための作業が増え、今進めたい開発が止まってしまっては困ります。
そこで、既存の仕事は継続し、新しく始める小さな仕事からCodex CloudとGitHubの使い方を試します。今回の数量表チェックは、そのための題材として位置づけています。
実務データを扱う前に確認すること
架空データで動作を確かめた後も、実際の案件資料をすぐに渡せるわけではありません。
まず、どの版の資料を対象にするのか、どこまでを比較・確認するのかを明確にする必要があります。比較対象の版が違えば、処理自体が正しくても、仕事として役に立たない結果になってしまいます。
あわせて、資料の機密性と、クラウドで処理することが許可されているかを確認します。そのうえで、目的に必要な範囲のデータを選んで渡すことが基本になると考えています。
前回の記事で書いた「投入」用フォルダーを、Codex Cloudへの資料の受け渡しにも使えるかは、まだ試していません。今回用意した非公開リポジトリも、実務資料を預けてよいという判断の根拠にはなりません。
処理結果についても、検出された項目だけを見て終わりにせず、期待した差分が出ているか、見落としや誤検出がないかを確認する必要があります。最終的な設計判断と成果品の品質に対する責任は、これまでどおり技術者が担います。
コードを裏側の道具として使う
今回の数量表チェックでは、私がdotに確かめたい内容を伝え、その先でCodex Cloudがプログラムを作ってテストしました。私が受け取ったのは、変更箇所や集計の不一致を確認するための結果です。コードを裏側の道具として使う流れが、少し具体的になりました。
実務へ進むなら、使った資料の版、比較条件、検出した箇所を技術者が追えることも必要です。操作を任せる範囲が広がっても、結果を確認し、判断する役割は残ります。
Codex Cloudは以前からありました。しかし、dotとつながったことで、私にとってのCodexは「自分で操作する開発ツール」から、「普段仕事を任せているAIが、必要に応じて使う専門家」へと変わりました。
今回は、dotからの依頼がクラウド上での作成・テストにつながるところまで確認しました。GitHubへの成果の保存とレビュー、実務資料を使った検証は、これからです。新しい小さな仕事で、その先の流れを確かめていきたいと思います。