こんにちは、TECH Street編集部です！
この記事では、2025年10月16日（木）に開催した「AI駆動開発エンジニア勉強会～各社の取り組みや課題から学ぶ会～」の登壇者の発表内容の紹介と、イベント中に回答しきれなかったQ&Aを記載しています。
登壇者はこちらの方々！
齋藤 悠太
パーソルキャリア株式会社
マネジャー
パーソルキャリアでdodaの開発に携わっており、現在はマイクロサービスを推進を担当しています。 特にJava、Spring、AWSといった技術領域に強い関心を持っています。 最近では生成AI技術の研究と実装に注力しています。
Sohei Takeno
株式会社SANU
テクノロジー本部長
Wantedlyで全社アーキテクトを務めた後、SANUに参画。ノーコードで構築された大規模システムをTypeScript・GraphQLで再設計し、技術とチームを内製化。ソフトウェア領域全般を管掌。
Akity
ノウンズ株式会社
VPoE
SIerにてOSS業務アプリのプリセールスとしてキャリアをスタート後、Web事業会社で複数サービスのEM、北米向けブランディングSaaSの技術責任者を歴任。BtoB SaaSのデータテクノロジー領域での組織づくりを経て、2025年3月に現職へ入社し、同年7月よりVPoEとしてエンジニア組織を率いる。
安全にAIエージェントを活用するための環境づくり
AI時代の『作り方』を設計する
レガシーソフトウェア vs 私たち with AI 〜仕様化テスト自動生成AIエージェント開発譚〜
Q&Aコーナー
（Q）AI駆動し始めて良かったことではなく、逆にキツいことってあれば聞いてみたいです。
齋藤：課題に対する第一選択肢がAIに寄ってしまう点は注意点だと考えています。大切なのは「How」ではなく「Why」でAIで実行が必要かどうか？を考えること。AIを使うこと自体が目的化しないようにしたいなと思います。
Takeno：AIを活用することで判断の機会が増え、意思決定を迫られる場面が多くなりました。その分、労働強度が高くなっていると感じています。
Akity：AIワークスロップに課題を感じています。
実装者のアウトプット量は確かに増えましたが、レビュワーへの負担が見過ごせない状況になっております。
問題を"それっぽくAIで解決した"だけの状態になっているケースが多々あり、本質的な解決策には至っていないことが見受けられます。
上記のような状況は、要件定義やその他ドキュメント作成などなど、多くの場面で見られるような課題となっています。
（Q）AI エージェント開発運用して、特にコスト・運用負荷という観点で懸念というか注意しなければいけないことはありましたか？
齋藤：プロンプトキャッシュが出る前は、コストが高くなりやすい課題がありました。プロンプトキャッシュにより現在ではその課題が解消されました。
（Q）導入前後で効果が出なかったケースや逆に悪影響を及ぼしたケースはありますか？
齋藤：コードレビューで利用するケースにおいて、不要なコメントが多くノイズが多いことが課題となっています。
（Q）コスト課題について、AIエージェントを使って効率化した結果、どの程度開発効率の向上が見込めたのか？
齋藤：（まだ具体的な効果測定はこれからの段階ですが）従来であれば1人で1か月かかっていた作業が、今後はおよそ1週間程度で完了するような効果が見込めると考えています。
（Q）AI エージェント導入によって、どのような指標（障害対応時間削減、運用コスト削減、ミス低減など）をどう測っていらっしゃいますか。
齋藤：生産性の指標として「Four Keys」を活用しています。
今後はその計測結果をもとに、AI導入による効果を評価していきたいと考えています。
Takeno：当初からAIを組み込んだ開発体制だったため、Before／Afterの比較はないです。ただし、プルリクエスト数などからアウトプット量の推移を確認し、一定の成果を見ています。
Akity：現在はまだ組織/チーム体制を整えている段階で、Four Keysなどの明確な測定手段までは至っていません。
障害対応時の復旧時間などは記録していますが、データが十分に蓄積されていない状況です。AIエージェントに頼り過ぎることで非効率になる領域は確実に存在するため、効率化できる領域と、そうではない領域をチームで見極めていくことが重要になると考えています。
（Q）Gatewayが逆に新しく出てきたサービス導入のネックになる可能性はありそうでしょうか？（例えば、実行環境やIFがGatewayによって限定されてしまうなど）
齋藤：LLM提供各社が新しいエンドポイントなどを出した際に、Gatewayの対応が追いついていない場合に遅れが生じるリスクがあります。ただし基本的にはOSSを利用するため大きな遅れは生じない想定です。
（Q）開発部隊がAI生成を前提とした「作り方の設計」を受け入れるには、どのようなはたらきかけ、ガイドライン・文化設計が必要でしたか？
齋藤：私たちは、これからルールづくりを進めていく段階です。現時点では、まず組織としてAI利用の安全性をしっかり担保することに重点を置いて取り組んでいます。
Takeno: マネジメントの立場としては、AI時代には従来の「生産性」の概念が大きく変わっていくと感じています。今後は少人数でも成果を上げられる体制づくりが求められており、その状態でどう結果を出していくかが、私のミッションだと捉えています。
Akity: 現在は隔週のペースで状況に応じた方針を伝えるようにしています。
AI関連の変化のスピードは凄まじく、数カ月で組織体制の見通しすら変わる可能性があると考えています。
AIありきのプロダクト開発において、これまでの組織/チームのあり方に凝り固まるのではなく、状況や結果を見ながら柔軟に判断していく段階と考えており、その考えをチームに頻度高く伝え続ける努力をしなければ、と考えております。
（Q）AI エージェント(コーディングエージェント) を内製をしているとやはり外部のツールとの差が出てきてしまい大変だと思いますが、外製のツールを使うよりも内製しつづける決断はどのようなものがありますか？
齋藤：コーディングエージェントに関しては内製し続けないという選択をしています。当初より安全な基盤作りが完了したら移行することを想定していました。
（Q）Difyのようなエージェント構築プラットフォームは日々進化しています。そのため、いちいちゼロからコーディングしてAIエージェントを作る必要は本当にあるのでしょうか。こうしたツールに慣れれば、エージェントの構築スピードは格段に向上します。では、コーディングAIを使ったエージェント構築と、外部プラットフォームを利用した構築の関係性は、どのように考えるべきでしょうか。
齋藤：AIエージェントをコーディングにより作成することでより柔軟性などが得られると考えています。特にプロダクトへの組み込みを想定している場合には必須と考えています。
（Q）SANUさんのサービス自体がきになりますね。（癒しの場所？ワーケーション？）
一般的に、こういったサービスであれば、どこかが出しているECサイト系を使うのが定番なのでしょうか？それとも各社独自にがんばってwebページを構築してるのでしょうか？あと、いま開発体制はどんな感じですか？
Takeno：自然立地の中に携帯だけでチェックインできるホテルを運営しています。月額制のサブスクリプション利用や共同所有など、ユニークなビジネスモデルです。そうした特性もあって、自社開発しています。元々ノーコード開発スタートで、ノーコードエンジニアとプロダクトマネージャーの３名からスタートし、現在は７名で開発を行っています。
（Q）SANUさんからもコスト面とかの課題あれば聞きたい
Takeno：AI活用を前提にチームを内製化しています。エンジニアの生産性が上がるならAIのコストも十分ペイできる、という考え方で進めています。「AIでのコスト面」という文脈では、今のところ課題というより、むしろコスト削減につながっていると感じています。
（Q）伴走開発の副次的な効果として、関数などにコメントがほぼほぼ残るようになってきたことに喜びを感じます。さて、コーディングエージェントをうまく使っていくうえで、コメントを英語にすべき？と悩むことがあります。このあたりコメントいただけませんか？
齋藤：AIエージェントを使うようになっても、当面はコードを読むこともまだまだあると思います。英語力の差もあると思うので、無理に英語で書く必要はないと考えています。
Takeno：AI だけに限って言えば、日本語でも英語でも分かるので大きな違いは感じていません。
ただし、やはりソースコードを読むだけでは分からない情報を残すことは非常に大事で、そういった情報は僕たちの場合は日本語で残しています。
（Q）弊社でも作り方の部分を規定しようと試行錯誤していますが、なかなかベストプラクティスが見つけられません。今回の登壇でお話しされたような規定に行きつくまでの苦労や試行錯誤が知りたいです。
Takeno：前職のWantedlyでチーム拡大のフェーズを経験したことが大きいです。そのときの知見を今の取り組みに活かしています。ベストプラクティスを探る際は、まずはトラディショナルなエンジニアリングの知見やルールをきちんと取り入れることから始めると良いと思います。
（Q）現状の駆動開発は完璧ではないとおもうのですが、セキュリティ脆弱性を孕むようなコードが生成される場合の流出防止策としてはどのようなツールを使っているのでしょうか。
齋藤：コードレビューもAIに任せることや、その他の脆弱性を検知できる製品を合わせて利用することでリスクを軽減できると考えています。
Takeno：前提として AI にコードを書かせる場合でもエンジニアがレビューするプロセスは入れています。
特にどのような情報も出すことができるバックエンド API の実装では、コード生成されたものをそのまま中身を見ずに出荷するということはしていないですね。一方フロントエンドでは、部分的にバイブコーディングも活用しています。
（Q）SANU様のいまのアーキテクチャとAI活用で、体感で何人分の採用を削減できていると思いますか？
Takeno：何と比較するかによるので伝え方は難しいですが、こういったものを全く導入しない場合と比較すると、2倍程度のコンパクトさは実現できていると思います。
（Q）導入の際にPoCではどう言った評価基準でユースケースを選びましたか？私も現状駆動開発を始めようとしておりますが、何を重視して導入する開発ユースケースを選ぶべきか悩んでいます。効果はきっと大事ですが、実現可能性ももちろん必要で考えなければ行けないものの優先順位が気になります。
Akity：導入によるインパクトと実現容易性で優先順位付けしております。
ただ、AIありきで考えたわけではなく、そもそもチームとして解決すべき課題の中で、AI活用により実現容易性を高められる可能性のある課題があったため、当課題をPoCとして選択した流れです。
（Q）ものすごい興味本位で聞くのですが、複雑度が200以上もあるコードって、どんなコードなんでしょうか・・・？怖くて触れないですねぇ・・・。
Akity： 1モジュールで、多くの役割や責務を担っておりました...
仰るとおりで怖くて触れないので、仕様化テストからはじめることにしました!!
（Q）AI開発の掟3つ以外もぜひ見たい・・・・
Akity： 例えば、ReactNative開発チームにはもともとテスト文化がなかったため、まず「どんなテストが必要か」「どこから始めるか」といった基本方針を決めるところからスタートしました。
他にも、統合テストでは「どの範囲までモック化すべきか？」など細かなルールを定義するなど、チーム内でのテストに対する共通認識づくりを進めました!!
（Q）知らないうちにマダンテが放たれていることもありますよね。。。
Akity：仰るとおりで、AIエージェントのできることを限定させるガードレールづくりはとても重要です!!
（Q）AI駆動開発していると、既存のシステムが世のお作法に則っていないせいで、AIがうまくソースコードを書きづらいのもネックですよね
オレオレアーキテクチャをAIが直そうとしても出力が安定しないという（人間が見てもわからないのですが）
Akity： リーダブルコードはAIにとってもリーダブルですよね!!
AI駆動開発も大切ですが、今まで通りチーム開発を強くすることは引き続きとっても大事なことだと考えています！！
（Q）AIがAIをレビューとは、具体的にどのように実行したの？
Akity： Claude Codeのサブエージェント機能でレビュー担当AIをつくりました。
また、テストの品質基準（例えば、カバレッジ基準やモック方針の遵守など）をドキュメント化して、上記レビュー担当AIに品質基準に基づいたレビューを実施させるようにワークフローを構築しました!!
（Q）Costの課題があったかどうか、アキティさんにもききたいです
Akity： 当発表内容ではClaude Max Plan 20x内で実施しており、コスト予測できる範囲で管理しておりました。
（Q）AIがAIをレビューするような分業制をとったとのことですが、それぞれの役割の設定は1つのClaude Codeでのコマンドでそれぞれ分岐させたのでしょうか？それともそれぞれ別のLLMやプロンプトの構成で実現させたのでしょうか？
Akity： すべてClaude Code上で実現しています。
Claude Codeサブエージェント機能で分業を実現しています。
また、Claude Codeコマンドがオーケストレーターとして全体統括する形です。
（Q）試す！試す！試す！は何回くらい試しましたか？
Akity：ちっちゃいのも合わせると100回を超えると思います。
当発表の開発をリードくださった方のSlack timesチャネルや結果をまとめてくださった文書をみるだけでも、上記試行錯誤量が伺えました!!
環境（例えばNode.js）エラーやループ処理がうまく動作しないケースなども多々あり、試行錯誤を重ねながら結果を検証されていました。
品質基準をあらかじめ言語化していたため、各試行の結果もAIエージェントに出力させることで、検証サイクルをまわしました。
（Q）最終的に、仕様化テストはすべて実現できたのか？
Akity：仕様化テストの対象も優先順位をつけており、優先順に実装しております。
現状ではまだ対象すべての実現には至っておりません。
（Q）AIレビューで自動化した結果は、人間側から見て、どれだけの正解率でした？LLMだから揺れると思ってますが100%？
Akity：対象コードの状態によりけりで、シンプルなコードだとチーム基準を満たす水準の出力を確認しております。
しかし、優先度の高い複雑度MAXのコードは、カバレッジは満たすものの、10 - 15%ほどのテストケースが基準を満たせていないことを確認しております。
（Q）仕様化テスト実施後は、リファクタリングしていく認識であっていますか？
Akity： あってます!!
当PoC実施前に、仕様化テスト実装後の話もチームで認識合わせしております！！
（Q）どこの時点で、必勝魔神完成と思えましたか？
Akity：今尚、完成ではなく、継続改善中です。
が、そもそもテストが無い状態からはじまっているため、プラスにしかならない状況だとも考えております!!
また、当取り組みを他チームへも横展開していく考えです！！
今回の登壇レポート一覧
