AIエージェントを「開発チーム」として動かすために、私たちが取り組んでいること

生成AIを使ってコードを書くことは、以前よりずっと身近になりました。

「この機能を作って」「このエラーを直して」「テストを書いて」「レビューして」と依頼すれば、AIがかなりの作業を進めてくれます。
実際の開発現場でも、AIを使うことで調査や実装のスピードが上がったと感じる場面は増えています。

一方で、AIにまとめて任せるほど、「誰が何を判断したのか」が見えにくくなるという課題もあります。
特に、ログイン、権限、通知、メール送信、申請や承認のように、少しの見落としが情報漏えい、二重送信、誤通知、権限不備といった事故につながる領域では注意が必要です。

実は、私たちも一時期、SNSなどで話題になっていた「AIで組織を作る」「AIに部署を持たせる」という考え方を試していました。

アウルキャンプは、SESを含めて開発やIT支援に関わる会社です。
そのため、社内のバックオフィス、営業、マーケティング、経理、人事・採用、開発まわりの業務をAIで効率化できないかと考えていました。

会社の部門ごとにAIエージェントを分ければ、実際の組織に近い動きができるのではないかと考えたからです。

しかし、これはうまくいきませんでした。

役割を分けるだけでは、それぞれのAIエージェントが別々に動いてしまい、情報や判断がうまくつながりませんでした。
営業が見つけた顧客課題が開発に十分伝わらなかったり、マーケティングの仮説が営業や制作に引き継がれなかったり、経理や管理面の制約が後から出てきたりします。

人事や採用のように、最終的には人が判断し、対話し、責任を持つ必要がある領域もあります。

さらに、部門やスキルを増やしたものの、実際の運用ではほとんど使わないAI部門やスキルも出てきました。
組織を充実させたつもりが、かえって「何のためにここまで部門を増やしたのか」が分かりにくくなる場面もありました

結果として、部署はあるのに部門間連携が弱い組織のような状態になってしまいました。

私たちは、このAI組織づくりは失敗だったと捉えています。

ただし、この失敗から得た学びもありました。
AIエージェントを活用するうえで大事なのは、単に役割や部署を増やすことではありません。
分けたエージェント同士を、目的に沿ってどう連携させるかです。

そこで私たちは、この失敗から得た知見を、ソフトウェア開発の工程に合わせて整理し直しました。
会社全体をAI組織にするのではなく、まずは事故リスクが出やすい開発工程に絞って、AIエージェントの役割と連携を設計することにしました。

この記事では、公開されているAIエージェント間メッセージングツールagmsgを活用した取り組みを紹介します。
テーマは、AIエージェントを単なる作業者ではなく、「開発チーム」として動かすことです。

AIに丸投げすると開発が危なくなることがある
私たちの考え方：AIを「1人の万能担当者」として使わない
近い考え方としてMetaGPTやChatDevがある
MetaGPT
ChatDev
AgileCoder
AgentCoder
HyperAgent、SWE-agent、OpenHandsは実行基盤に近い
その運用を実際に回すためにagmsgを使う
agmsgでAIエージェントをチームとして動かす
作業量ではなく事故リスクでプロセスを変える
Architect は「別視点の設計責任」を持つ
Reviewer は「好み」ではなく、判断基準に照らして確認する
副作用のある処理では「押した後」を重視する
AI開発で大事なのは、ツール選びだけではない
開発現場で求められる「実装力」と「テスト力」は変わる
まとめ

AIに丸投げすると開発が危なくなることがある

AIはコードを書くのが得意です。
しかし、ソフトウェア開発は「コードを書くこと」だけではありません。

実際の開発には、次のような工程があります。

工程	内容
要件整理	何を作るのか、なぜ作るのかを決める
設計	どういう構造で作るかを決める
実装	実際にコードを書く
レビュー	要件や設計に合っているか確認する
テスト	正しく動くか、壊れないか確認する
最終判断	リリースしてよいか判断する

人間の開発チームでは、これらの役割が分かれています。

しかし、AIに「全部やって」と頼むと、次のような状態になりやすくなります。

AIが勝手に仕様を補ってしまう（いや、そこは決めてない）
設計と実装の判断が混ざってしまう（その判断、誰がした？）
本当に要件に合っているか分かりにくい（動いてはいる。でも合っているとは限らない）
レビューが自己確認のようになってしまう（自分で作って自分でOKと言っている状態）
テストが「とりあえず動くか」だけになりやすい（動くことと、出してよいことは別）
セキュリティや権限、二重送信などのリスクが見落とされる（そこを見落とすと事故になる）

AIは便利ですが、AIに任せる範囲や役割を決めないと、開発の責任範囲が曖昧になります。

私たちの考え方：AIを「1人の万能担当者」として使わない

私たちは、AIを単なる便利な作業者として使うのではなく、開発チームの一員として役割を分けて使うことを重視しています。

たとえば、人間の開発チームには次のような役割があります。

PM
アーキテクト
開発者
レビュアー
QA担当

これと同じように、AIエージェントにも役割を持たせます。

AIエージェントの役割	担当すること
PM	要件整理、設計方針、最終判断
Architect	PMとは別視点での技術設計、リスクの洗い出し、探索的QA
Builder	実装、テスト作成
Reviewer	要件、設計、既存仕様との照合

このように役割を分けることで、AIに丸投げするのではなく、開発工程として管理しながらAIを使うことができます。

近い考え方としてMetaGPTやChatDevがある

私たちが考えていることは、まったく新しい発想というより、人間の開発組織の役割分担を、AIエージェントの役割分担に写像する取り組みです。

この考え方に近いものとして、MetaGPT、ChatDev、AgileCoder、AgentCoderなどがあります。

MetaGPT

かなり近いものの一つがMetaGPTです。

MetaGPTは、AIエージェントで「ソフトウェア会社」を模倣する発想のマルチエージェントフレームワークです。公式リポジトリでは、複数のGPTに異なる役割を割り当て、複雑なタスクに協調して取り組むための仕組みとして紹介されています。

GitHub: FoundationAgents/MetaGPT
論文: MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework

特に近い点は、役割を分けてソフトウェア開発の工程を進めるところです。MetaGPT では、Product Manager、Architect、Project Manager、Engineer、QA Engineer などの役割が登場します。

観点	MetaGPT	私たちの運用イメージ
要件整理	Product Manager	PM
設計	Architect	PM、Architect
進行管理	Project Manager	PM
実装	Engineer	Builder
品質確認	QA Engineer	Reviewer
設計リスクの確認	Architect / QA Engineer	Architect、Reviewer

MetaGPT は、ソフトウェア会社の工程をAIエージェントで再現するフレームワークに近いものです。

ただし、私たちの運用では、MetaGPT の役割をそのまま1対1で置き換えているわけではありません。
たとえば、MetaGPT の QA Engineer に近い役割は Reviewer ですが、私たちの Architect も、設計時に洗い出したリスクを実装後の探索的QAまで追いかけるため、品質確認の一部を担います。

つまり、私たちの運用では、Architect は単なる設計担当ではなく、設計リスクを最後まで追跡する役割として位置づけています。

ChatDev

ChatDevも近い考え方です。

ChatDevは、LLMエージェントを使って、設計、コーディング、テストといったフェーズを会話ベースで進めるソフトウェア開発フレームワークです。論文では、専門化されたエージェントが design、coding、testing の各フェーズに参加すると説明されています。

GitHub: OpenBMB/ChatDev
論文: ChatDev: Communicative Agents for Software Development

ChatDev の公式リポジトリでは、ChatDev 1.0 が仮想ソフトウェア会社として、CEO、CTO、Programmer などのエージェントを使い、設計、コーディング、テスト、ドキュメント作成を進めるものとして紹介されています。

今回の話に置き換えると、次のように対応づけられます。

ChatDevの役割イメージ	私たちの運用イメージ
CEO	PM
CTO	PM、Architect
Designer	Architect
Programmer	Builder
Reviewer	Architect
Tester	Architect、Reviewer

ChatDev の Reviewer、Tester は、この記事の文脈では Reviewer だけでなく、Architect にも一部近い役割です。

私たちの運用では、Architect が設計リスクを洗い出し、そのリスクが実装後に解消されているかを探索的QAで追いかけます。

一方で Reviewer は、要件や既存仕様などの ground truth と照合する役割に寄せています。

ChatDev は「仮想ソフトウェア会社を作る」発想に近いものです。

一方で、私たちが重視しているのは、実際の開発現場で事故が起きやすい領域に対して、どの役割が、どの基準で止めるのかまで決めることです。

AgileCoder

AgileCoderは、より開発プロセスに寄った研究です。

AgileCoder は、Agile methodology をマルチエージェントシステムに組み込み、Product Manager、Scrum Master、Developer、Senior Developer、Tester のような役割をエージェントに割り当てます。スプリント単位で開発を進める点も、現実の開発工程に寄っています。

論文: AgileCoder: Dynamic Collaborative Agents for Software Development based on Agile Methodology

近い点は、AIエージェントを単独作業者ではなく、開発プロセス上の役割として扱うところです。

私たちの運用でも、AIに「全部やって」と頼むのではなく、PM、Architect、Builder、Reviewer という役割を分けて、工程ごとの責任を明確にしようとしています。

今回の話に置き換えると、次のように整理できます。

AgileCoderの役割イメージ	私たちの運用イメージ
Product Manager	PM
Scrum Master	PM
Developer	Builder
Senior Developer	Architect、Reviewer
Tester	Reviewer、Architect

AgileCoder は、スプリント単位の開発プロセスをAIエージェントに割り当てる点で、かなり実務プロセスに近い考え方です。

一方で、私たちの運用では、スプリント運用そのものよりも、事故リスクに応じて確認範囲や参加する役割を変えることを重視しています。

AgentCoder

AgentCoderは、もう少しコード生成に寄った研究ですが、役割分担の考え方として参考になります。

AgentCoder は、programmer agent、test designer agent、test executor agent で構成されます。コードを書く役、テストを設計する役、テストを実行してフィードバックする役を分けている点が特徴です。

論文: AgentCoder: Multi-Agent-based Code Generation with Iterative Testing and Optimisation

今回の話でいうと、programmer agent は Builder に、test designer agent は Architect が持つQA観点に近いです。

test executor agent は、私たちの運用では Reviewer そのものというより、Reviewer や Architect が判断するときの根拠になるテスト実行結果に近い位置づけです。

AgentCoderの役割	私たちの運用イメージ
programmer agent	Builder
test designer agent	Architect
test executor agent	Reviewer、Architect の判断材料
feedback to programmer	Reviewer から Builder への差し戻し、または PM 判断による修正指示

私たちが考える Architect は、単に設計するだけでなく、設計時に見つけたリスクをテスト観点まで追跡する役割です。

この点で、AgentCoder の「テストを設計する役」と「テストを実行する役」を分ける考え方とは相性が良いと感じています。

HyperAgent、SWE-agent、OpenHandsは実行基盤に近い

一方で、HyperAgent、SWE-agent、OpenHandsは少し別の軸にあります。

HyperAgentは、Planner、Navigator、Code Editor、Executor などの役割を持つ、汎用的なソフトウェアエンジニアリングエージェントとして提案されています。

SWE-agentは、AIエージェントがGitHub Issueを受け取り、リポジトリを操作して修正するための仕組みです。論文タイトルにもあるように、Agent-Computer Interface、つまりエージェントが開発環境を扱いやすくするインターフェース設計が重要なテーマです。

OpenHandsは、AIソフトウェア開発エージェントの実行環境やプラットフォームに近いものです。コードを書き、コマンドラインを操作し、ブラウザを使うような、人間の開発者に近い作業環境をエージェントに提供する方向です。

これらは、どちらかというとAIエージェントが開発環境で作業するための実行基盤に近いものです。

ここで注意したいのは、MetaGPT、ChatDev、AgileCoder、AgentCoder が「運用ではない」という意味ではないことです。特に AgileCoder は、アジャイル開発の流れをマルチエージェントに組み込むという意味で、かなりプロセス寄りです。

ただ、私たちが今回整理したいのは、既存のフレームワークと自社の取り組みを優劣で分けることではありません。

近い先行例を参考にしつつ、私たち自身がAI組織を試したときに詰まった点は、もっと素朴なものでした。

AIエージェントの役割分担には、大きく二つのやり方があります。

一つは、Claude や ChatGPT のような一つのAI環境の中で、プロンプトやスキルを使って役割を分ける方法です。もう一つは、Claude Code、Codex、Gemini CLI など、別々のAIエージェントを独立した担当者として動かす方法です。

もし一つのAI環境の中で完結するなら、スキルやサブエージェントで十分な場面もあります。わざわざ別の仕組みを使わなくても、PM用のスキル、レビュー用のスキル、QA用のスキルを用意すればよいからです。

ただし、どちらの方法でも、「役割を分けたから抜け漏れがなくなる」わけではありません。PM役が決めた前提をBuilder役が見落とすこともありますし、Architect役が出したリスクがReviewer役の確認観点に入らないこともあります。

つまり問題は、AIを何役に分けるかだけではなく、分けた役割をどう密に連携させるかです。

たとえば、AIがコードを編集できる環境や、役割分担されたエージェントの枠組みがあっても、それだけでは次のことは決まりません。

どのタスクをAIに任せてよいのか
どのタスクはArchitectの確認を通すべきか
Builder が実装に入ってよい条件は何か
Reviewer は何を根拠にOKまたはNGを判断するのか
最後に誰がリリース判断をするのか

私たちが整理したいのは、こうした判断を各役割の中で閉じさせず、前提、リスク、実装結果、レビュー結果を次の役割へ確実に渡すための連携設計です。

近い先行例はあります。特に MetaGPT、ChatDev、AgileCoder、AgentCoder は、AIエージェントでソフトウェア開発の役割を分けるという意味でかなり近いです。

ただし、私たちの運用モデルで特に重視しているのは、次の点です。

実装量ではなく、事故リスクで軽量パス、準重量級ライト、準重量級ヘビー、重量級フローを分ける
Architect を独立設計だけで終わらせず、探索的QAまで持たせる
Reviewer を好みのレビューではなく、ground truth との照合に寄せる
GO条件と severity を明文化する
PMが最終判断を持つ
エージェント間の実際のハンドオフを行う

ここでいう ground truth とは、AIの推測ではなく、要件、設計メモ、既存仕様、テスト結果、ログ、実際のコードなど、判断の根拠として優先する情報のことです。

既存の先行例が「AIでソフトウェア会社を模倣する」発想に近いとすれば、私たちの関心は「AIエージェントを、現実の開発工程の責任分界で運用する」ことにあります。

ここが、単なるマルチエージェント構成ではなく、実務の開発プロセスとして考えたいポイントです。

その運用を実際に回すためにagmsgを使う

ここまでの話は、MetaGPT、ChatDev、AgileCoder、AgentCoderと近い「考え方」の話です。

一方で、agmsgを使う理由は少し違います。

agmsgは、開発組織をAIで模倣するための思想そのものではなく、分けた役割を疎結合のまま終わらせず、密に連携させるための連絡路として使っています。

複数のAIエージェントを使うだけなら、手元でチャットをいくつか開いて、結果を人間がコピーして渡すこともできます。

しかしその方法では、次のような問題が起きます。

PMが何を前提に判断したのか残りにくい
Architect が出したリスクを Builder が見落としやすい
Builder の実装結果を Reviewer に渡すとき、人間が要約を間違えることがある
Reviewer の指摘が PM の最終判断までつながらないことがある
どのエージェントが、どの役割で、何を引き継いだのか追いにくい

AIエージェントをチームとして動かすには、単に複数のチャットを使うだけでは足りません。

役割ごとの発言、判断、申し送りを残しながら、次の担当へ渡す仕組みが必要になります。

agmsgは、そのための連絡路として使っています。

もちろん、同じAIツールの中だけで完結するなら、そのツールが持っているスキル、マルチエージェント機能、サブエージェント機能を使う選択肢もあります。

たとえば、すべてを Claude 系のエージェントだけで進めるなら、Claude 側のスキルやマルチエージェント機能で十分な場面もあります。

それでもagmsgを使う理由は、特定のAIツールの中に閉じない運用をしたいからです。

Claude Code、Codex、Gemini CLI など、異なるCLI型エージェントを同じチームに置き、それぞれを独立した担当者として扱えます。

PMはClaude、BuilderはCodex、Reviewerは別のCodex、というように、役割ごとに使うエージェントや実行環境を分けられます。

このように役割ごとに異なるエージェントを使い分けられることは、実務上かなり重要です。

また、同じ親エージェントの中のサブエージェントではなく、別プロセスの独立したエージェントとして動かせるため、担当ごとの視点が混ざりにくくなります。

これは、レビューを自己確認で終わらせないためにも大事です。

この形にするメリットは、単に「複数のAIを使える」ことではありません。

実務上は、次のような効果があります。

メリット	何がよくなるか
判断の混線を減らせる	PMの要件判断、Architectの設計リスク、Builderの実装判断、Reviewerの確認結果を分けて扱える
引き継ぎ漏れを減らせる	Architect が見つけたリスクを Builder や Reviewer に明示的に渡せる
レビューを自己確認にしにくい	実装したエージェントとは別の独立したエージェントに確認させやすい
後から追いやすい	どの役割が、どの前提で、何を依頼・判断したのかを会話として残せる
得意なエージェントを使い分けられる	設計、実装、レビューなどで、Claude Code、Codex、Gemini CLI などを役割に応じて選べる
構成を組み替えやすい	最初はClaudeだけで始め、後から実装だけCodexに任せる、レビューだけ別エージェントに分ける、といった変更をしやすい

特に大きいのは、レビューとQAの独立性です。

実装したAIがそのまま「問題ありません」と言うだけでは、人間の開発チームでいう自己レビューに近くなります。別の役割、別のエージェント、別の視点で確認することで、見落としを減らしやすくなります。

agmsgは、AIエージェント同士をメッセージで連携させるためのオープンソースツールです。GitHubではfujibee/agmsgとして公開されており、Claude Code、Codex、Gemini CLI、GitHub Copilot CLI など、複数のCLI型AIエージェントを同じチーム内で会話させるための仕組みとして紹介されています。

特徴は、構成がシンプルなことです。

公式の説明では、MCPサーバーや常駐デーモンを使うのではなく、Bash と SQLite を使ってローカル環境でメッセージをやり取りする仕組みになっています。

GitHub: fujibee/agmsg
目的: CLI型AIエージェント同士のメッセージ連携
対応例: Claude Code、Codex、Gemini CLI、GitHub Copilot CLI など
実装方針: Bash と SQLite を使ったローカルメッセージング

私たちはagmsgを、PM、Architect、Builder、Reviewer の間で前提やリスク、実装結果、レビュー結果を引き継ぐための連絡路として使っています。

こうした実務上の試行錯誤を進められるのは、agmsgを作り、公開し、改善を続けてくださっている作者・メンテナーの方々のおかげです。便利なツールを公開してくださっていることに、感謝したいと思います。

agmsgでAIエージェントをチームとして動かす

agmsgを使うと、複数のAIエージェントに役割を持たせ、メッセージを通じて作業を引き継がせる流れを作れます。たとえば、次のような流れです。

PM役のAIが要件と設計方針を整理する
Architect役のAIが別視点で設計案やリスクを出す
Builder役のAIが実装する
Reviewer役のAIが要件や既存仕様と照らし合わせる
最後にPM役がリリースしてよいか判断する

この流れを作ることで、AIをただのチャット相手として使うのではなく、役割を持った開発チームとして運用しやすくなります。

このときagmsgが担っているのは、AIに賢く考えさせる部分ではありません。

PM、Architect、Builder、Reviewer の間で、判断材料や依頼内容を渡す部分です。

人間の開発チームでいえば、チケット、コメント、レビュー依頼、QA申し送りに近い役割です。

会話を残しながら担当を切り替えられるため、「誰が何を見て、何を判断したのか」を追いやすくなります。

私たちにとってagmsgは、外部の便利なメッセージ連携ツールであると同時に、AIエージェントを開発チームとして動かすための協調基盤として活用できるものです。

作業量ではなく事故リスクでプロセスを変える

AI開発では、作業の重さをコード量だけで判断すると危険です。

見た目は小さな修正でも、次のような機能は慎重に扱う必要があります。

ログイン
パスワードリセット
招待メール
通知
申請、承認
決済、請求
個人情報の変更
権限設定
監査ログ
メール送信

これらは、画面やコードの変更量が少なくても、事故が起きたときの影響が大きい領域です。

たとえば、パスワードリセット画面であれば、単に「メールが送れるか」だけでは十分とは言えません。

ボタンを連打してもメールが何通も送られないか
成功後にもう一度送信できてしまわないか
存在しないメールアドレスかどうかが画面上で分かってしまわないか
戻るボタンやリロードで再送信されないか
ログとして追跡できるか

ここまで確認しておくと、実装後の不安を減らせます。

そのため私たちは、タスクを次のように分けています。

分類	内容
軽量パス	文言修正、表示調整、既存仕様に沿った小さな変更など、事故リスクが小さいもの
準重量級ライト	副作用や状態遷移の確認は必要だが、既存仕様に沿っており、Architect の独立設計までは不要なもの
準重量級ヘビー	認証、権限、通知、再送信可否、冪等性、cooldown など、設計判断やリスク検証が必要なもの
重量級	DB、API契約、権限モデル、監査、テナント分離、ADR級判断など、後戻りコストが高いもの

すべての開発を重くするとスピードが落ちます。
一方で、危ないものまで軽く扱うと事故につながります。

そのため、私たちは実装量ではなく、事故リスクに応じて開発プロセスを変えることを大事にしています。

Architect は「別視点の設計責任」を持つ

この仕組みの中で重要なのが、Architect の役割です。

PM は、主に「何を作るべきか」「業務として正しいか」「最終的にリリースしてよいか」を見ます。
一方で Architect は、「その作り方で安全に運用できるか」「後から変更しやすいか」「事故が起きやすい構造になっていないか」を見ます。

つまり Architect は、PM の案を否定する役割ではありません。
また、単なるレビュー担当でもありません。

Architect は、PM とは別の立場から、設計そのものを検証する役割です。

たとえば、ある機能を作る場合でも、PM は「業務上この流れで問題ないか」を中心に考えます。
Architect はそれに対して、次のような観点を確認します。

この状態遷移で破綻しないか
権限チェックをどの層で行うべきか
二重送信や再実行に耐えられるか
エラー時に安全に復旧できるか
監査ログとして必要な情報が残るか
既存の設計方針やAPI契約と矛盾しないか
将来の変更で大きな手戻りにならないか

さらに Architect は、設計案を出して終わりではありません。

設計時に洗い出したリスクが、実装後に本当に解消されているかも確認します。
たとえば、二重送信のリスクを設計時に指摘したのであれば、実装後にそのリスクがUI・API・テストのどこで防がれているかを確認します。

つまり Architect は、単に「別案を出す人」ではなく、設計リスクを最後まで追跡する役割です。

ここが、AIに単にコードを書かせる開発とは大きく違う点です。

Reviewer は「好み」ではなく、判断基準に照らして確認する

AIにレビューを依頼すると、もっともらしい指摘がたくさん出ることがあります。

もちろん、その中には有益な指摘もあります。
一方で、「今回の要件とは直接関係ない指摘」や「一般論としては正しいが、今すぐ対応すべきではない指摘」が含まれることもあります。

現場では、指摘の数が多いことよりも、その指摘が開発判断に使えるかどうかが重要です。

そこで私たちは、Reviewer の役割を明確にしています。

Reviewer は、好みや一般論だけで判断しません。
次のような基準に照らして確認します。

セキュリティ上の問題がないか
既存の設計方針に反していないか
要件を満たしているか
データの整合性が保たれているか
既存仕様を壊していないか
運用上の問題がないか

そして、問題の大きさを次のように分けます。

区分	意味
BLOCKER	必ず止めるべき重大な問題
MAJOR	原則として修正すべき問題
MINOR	後続対応でもよい軽微な問題
NIT	好みや細かい改善レベル

このようにすることで、AIレビューを「なんとなくの指摘」ではなく、修正すべきか・受け入れるか・後回しにするかを判断できるレビューに近づけています。

副作用のある処理では「押した後」を重視する

メール送信、申請、承認、決済などは、ボタンを押すとシステム内外に影響が残ります。

このような処理を、私たちは「副作用のある処理」として慎重に扱っています。

副作用のある処理では、単に「ボタンを押せるか」ではなく、押した後に何が起きるかを確認します。

具体的には、次のような観点です。

送信中にボタンが押せない状態になるか
ダブルクリックしても1回だけ実行されるか
Enterキーを連打しても1回だけ実行されるか
成功後にもう一度送信できない状態になっているか
戻る・リロードで再実行されないか
エラー時に安全に再試行できるか
ユーザーに見せてよい情報だけを表示しているか
操作ログや監査ログが残るか

AI開発で大事なのは、ツール選びだけではない

AI開発では、どのAIモデルを使うか、どのエディタを使うか、どの開発支援ツールを使うかに注目が集まりがちです。

もちろん、ツール選びは重要です。
しかし、実際の開発でより大事なのは、AIをどの工程に、どの責任範囲で参加させるかです。

AIにコードを書かせるだけなら、比較的始めやすくなっています。
難しいのは、AIを開発工程の中で安全に使うことです。

そのためには、次のような設計が必要です。

誰が要件を決めるのか
誰が設計するのか
誰が実装するのか
誰がレビューするのか
誰がテスト観点を出すのか
誰がリリース判断をするのか
何を基準にOKとするのか

私たちは、AI時代の開発では、こうした責任範囲・判断基準・工程設計を整理することが非常に重要になると考えています。

ただし、現時点で開発工程を100%AIだけで完結できるかというと、まだその段階には達していません。

AIは実装やレビューを大きく支援してくれます。
一方で、最終的な判断には人の確認が必要です。

特に、UI/UXの違和感、画面上の使いやすさ、ブラウザ上での実際の挙動確認は、AIだけでは判断しきれない部分があります。

また、コードレビューについても同様です。AIによるレビューは有効ですが、設計意図、事業上の優先順位、将来の運用を踏まえた判断には、人の目が必要です。

私たちは、AIを開発工程に組み込みながらも、人が確認すべき領域を明確に残すことが重要だと考えています。

開発現場で求められる「実装力」と「テスト力」は変わる

この変化は、SESに限った話ではありません。
受託開発、自社開発、社内システム開発、QA業務など、ソフトウェア開発に関わる多くの現場に関係します。

AIエージェントが実装、レビュー、テスト作成まで担えるようになると、影響を受けるのはテスト業務だけではありません。
実装業務の中身も変わっていきます。

これまでは、仕様に沿ってコードを書く力そのものが大きな価値でした。
しかし、AIがコードを書けるようになると、単に指示された通りに実装するだけの仕事は、相対的に価値が下がりやすくなります。

もちろん、実装そのものが不要になるわけではありません。
むしろ、AIがコードを書くようになるほど、「何を作るべきか」「どう作るべきか」「AIが作ったものが正しいか」を判断する力が重要になります。

たとえば、次のような観点です。

仕様や要件を正しく理解できているか
設計意図に沿った実装になっているか
既存仕様や既存コードと矛盾していないか
認証、権限、通知、再送信可否などのリスクを考慮できているか
AIが作ったコードをレビューできるか
自動テストで何を担保すべきか判断できるか
ブラウザ上で実際に使って違和感がないか確認できるか
最終的にリリースしてよい状態か判断できるか

テスト業務も同じです。
手順書に沿って画面を操作し、結果を記録するだけのテスト実行業務は、AIや自動化の影響を受けやすくなります。

一方で、テストそのものが不要になるわけではありません。
むしろ、何を確認すべきかを決めるQA設計、事故リスクを見つけるレビュー、AIが作った成果物の ground truth 照合ができる人材の価値は高まると考えています。

これは、SESの現場にも大きく関係します。

SESでは、現場ごとに開発体制や担当範囲が異なります。
その中で、単に指示された作業をこなすだけではなく、AIを使って実装を進める力、設計リスクを見つける力、要件や既存仕様に照らして成果物を確認する力が重要になっていくはずです。

つまり、これからの開発現場で求められる人材像は、単に作業をこなす人から、開発プロセスの中で品質を支えられる人へ変わっていくと考えています。

具体的には、Builder、Architect、Reviewer に近い視点です。
AIを使って実装を進める力、設計リスクを見つける力、要件や既存仕様に照らして成果物を確認する力。
こうした力を持つことが、これからの現場ではより重要になると考えています。

まとめ

AIは、開発を大きく効率化してくれます。
しかし、AIにすべてを丸投げすればよいわけではありません。

むしろ、AIが強力になったからこそ、次のような考え方が重要になります。

AIに役割を持たせる
設計と実装を分ける
レビュー基準を明確にする
副作用や状態遷移まで確認する
事故リスクに応じて開発プロセスを変える
最終判断は責任者が行う

私たちは、公開されているツールである agmsg を活用し、AIエージェントを単なる作業者ではなく、役割と責任を持った開発チームとして運用する方法を模索しています。

こうしたツールを作ってくださる方々への感謝を忘れずに、実際の開発現場で得られた知見を共有していきたいと考えています。

AIによって開発は速くなります。
だからこそ、どこで確認し、どこで止め、誰が判断するのかを明確にする必要があります。

これは、AIを現実の開発工程に接続する取り組みでもあります。

AIを開発や業務にどう組み込むか、一緒に整理しませんか？

アウルキャンプでは、AIを単に導入するだけでなく、実際の業務フローや開発工程に合わせて、安全に活用できる形を一緒に設計しています。

たとえば、次のようなお悩みがあればご相談ください。

ChatGPTやAIツールを使い始めたが、業務改善や開発効率化につながっていない
AIを開発工程に取り入れたいが、どこまで任せてよいか分からない
レビュー、テスト、ドキュメント作成、問い合わせ対応などを効率化したい
メール、Excel、PDF、チャット、社内申請などの確認・転記・下書き作業を減らしたい
AIを使いたいが、情報漏えいや誤回答が不安
既存のWebサイト、業務システム、IT運用を改善したい

いきなり大きなAIシステムを作る必要はありません。
まずは、現在の業務や開発工程を確認し、AI化できる業務、AIに任せるべきではない業務、人が確認すべき業務を整理するところから始められます。

アウルキャンプでは、無料相談から、AI業務診断、小さな1業務実装、月額伴走まで対応しています。

社外AI業務改善室

AIを開発や業務にどう取り入れるべきか、まずはお気軽にご相談ください。