※この記事は、2025年10月に開催されたイベントでの発表内容をレポートしたものです。
登壇者はこの方
齋藤 悠太
パーソルキャリア株式会社
マネジャー
パーソルキャリアでdodaの開発に携わっており、現在はマイクロサービスを推進を担当しています。 特にJava、Spring、AWSといった技術領域に強い関心を持っています。 最近では生成AI技術の研究と実装に注力しています。
齋藤：パーソルキャリア株式会社のdodaシステムアーキテクト部 dodaマイクロサービスグループでマネジャーを務めている齋藤と申します。
SIer、不動産系事業会社を経験し、2020年9月にパーソルキャリア株式会社に中途入社しました。入社後はdodaのバックエンド開発を中心に担当し、2023年頃から現在のマイクロサービス化を推進しています。
普段はJava、Spring、AWSといった技術要素を触ることが多いのですが、直近ではAI周りに力を入れて取り組んでいます。
AI活用への課題
AIで実現したいこと
私たちがAIの開発で使いたいなと思い始めたのは、2024年の夏頃でした。
この頃はまだAIエージェントの知名度はそこまでなかった頃だと思います。GitHub Copilotが使えて当たり前で、AIによるコードレビューなども出てきたくらいだと思っています。
私たちはまだCopilotも使えない状態だったので、使いたいと思っていましたし、レビューも自動化できたらいいなと考えていました。
そこで、戦略的にAIの活用を検討するために動き始めました。
AI導入に対する懸念
ただ、AIの導入に対して、私たちの組織ではいくつか大きな課題がありました。特に大きかったものは、社内のコンプライアンスチェックです。
私たちの組織は比較的大きい規模の会社になっていて、新しい外部のウェブサービスを利用する際にはコンプライアンスチェックが必要となっています。
AIの利用を相談した際に指摘のあったものの例が記載されているのですが、例えば以下のようなものがありました。
Bedrockによる解決
これらの課題に対して、私たちはBedrockを活用することにしました。
こちらに記載の内容はAWSのドキュメントからのものになるのですが、Bedrockは入力したプロンプトやAIが生成した内容を保存しないと明記されています。
私たちもこれを使って課題を解消できるということが分かったので、生成AIを活用していくことになりました。
AIを組み込み始める
AIコードレビュー
最初に取り組んだのがAIのコードレビューです。CodrabitをフォークしたBedrock AI PR reviewerというOSSがあるのですが、当時はこちらを選択しました。
これは比較的簡単に導入できて、良い成果になったと振り返っています。
上の図のように、PRに対してAIが日本語でレビューコメントを提供します。例えば、例外処理が一般的すぎる場合、具体的な例外（UnknownHostException）をキャッチし、適切なログ出力やエラー処理を行うことを推奨するといった、実践的なアドバイスが得られます。
AIコード生成ツールを自作
続いて取り組んでいたのは、コード生成支援の導入というところです。
本当はGitHub Copilotを使いたかったのですが、様々な事情があって導入できなかったので、じゃあ自分たちで作っちゃおうかというところで作ってみることにしました。
私たちのメインのIDEはIntelliJを使っているのですが、IntelliJのプラグインを自作して、こちらを実現しています。
内部的にはLLMにコードと指示文を渡しているだけで、きちんと生成してくれるようになりました。左の画面のところが指示文になるのですが、ユーザーが指示を入力すると、その指示に基づいてコードが生成されるシンプルな仕組みです。build.gradleを参照して使用しているライブラリを調べ、それに基づいてコードを生成する機能を実装しました。
AIエージェントの登場
様々なAIエージェントが登場
こういった取り組みを進めていたのですが、2025年のはじめ頃にAIエージェントが流行し始めました。
- Cline
- Cursor
- Windsurf
- Claude Code
GitHub Copilotのようなコード生成支援を導入しようと思っていたのに、気づいたら「コードを生成してくれて」「テストコードを実行してくれて」「そのテストが失敗したら修正までしてくれる」というところまで、できるようになったと知った時は、すごい衝撃を受けたのを覚えています。
そこで、私たちはこのAIエージェントを導入できないかというところの検討を始めました。
AIエージェントにより新しい課題が生まれる
ただ、AIエージェントを導入するにあたっては、またこれまでとは違った課題があるというのが分かりました。
私たちが気にした課題の大きなものとしては、こちらに記載されているものになります。
意図しない処理が実行されるリスク
- rm -Rf ~/（ホームディレクトリの削除）の問題については、Xなどでも話題になりました。
- インターネット接続によりデータ漏洩の危険性もあります。
コスト課題
- エージェントは繰り返しツールを実行して処理を進めていくことになるので、これまでよりも多くのコストがかかることになると考えていました。
モデル利用に関する問題
- 私たちはBedrockを使っていこうとなったのですが、ちょうどClaude CodeがリリースされたタイミングでSonnet 3.7がリリースされたと思うのですが、このバージョンからBedrockもクロスリージョン推論の利用が前提となりました。
- これまでであれば、Bedrock使う際にも東京リージョンの中で利用していたのですが、クロスリージョンとなってしまうと、他のリージョンがセットで必要になります。
- 私たちのAWS環境では、東京リージョン以外の利用が禁止となっているので、ここから実質的にSonnet 3.7以降が利用できなくなりました。
AIエージェントの作成
ここからが私たちがAIエージェントの課題へどのように向き合ったのかをご紹介いたします。
AIエージェントの仕組み
最初に、AIエージェントの仕組みをご紹介しようと思っています。すでにご存知の方も多いかと思うのですが、改めてご説明させてください。
登場人物は主に3人
- ユーザー：コードの生成用AIエージェントを利用するのであれば、私たち開発者というところになります
- AIエージェント：これはClaude CodeやCursorを想像してもらえればなと思います
- LLM：OpenAIやAnthropicのAPIと考えてもらって大丈夫です
最初にユーザーがAIエージェントに対して指示を出していきます。
この例ですと、「xxx.javaのパフォーマンスを改善して」という指示を出すということを想定します。
次に、AIエージェントはユーザーの指示を受け取って、もともと用意していたシステムプロンプトにユーザーからの指示を付け加えて、LLMに投げるという形です。
以下はプロンプトの具体的なイメージになるのですが、このような例になっています。
ここの中身は、指示文と、そのAIエージェントの中で使うことができるツールを列挙してあげるというところと、最後にユーザーからの指示文を含めてあげて、これをLLMに渡すという形です。
補足：ツールの呼び出し方法
こちらは補足になるのですが、LLMのAPIではプロンプトとツールは別のパラメーターとして渡してあげます。
資料の左側の図にあるのが、利用可能なツールの一覧をLLMにリクエストする時のイメージのJSONとなっています。利用可能なツールとそのツールの詳細な説明や、呼び出す時のパラメーターなどをOpenAPIの形式で指定できるという形です。これらのツールをまとめて配列にしたものをリクエストで送るイメージです。
LLMからの呼び出し結果というのは、右上の図のようにツールユースという形で利用するツールと、そのツールに渡すパラメーターが返ってくるという形です。
AIエージェントはツールを実行したら、右の下の図のようにツールの実行結果をLLMにもう1回APIとして渡してあげるという必要があります。
プロンプトをLLMに渡すとツールの実行指示がLLMからレスポンスされるという形になります。
返ってきた結果を受けて、AIエージェントはツールの実行をします。
各種ツールを実行した後に、その結果をLLMに渡してあげる形になります。
この一連の流れ（ツールの実行指示が来て、ツールを実行して、LLMにツールの実行結果を返してあげる）がサイクルになっていて、これをユーザーが与えたタスクが完了するまで繰り返していくことになります。この部分がAIエージェントとしての中心部分となるというところです。
LLMがツールの実行の指示がなくなったというタイミングで、エージェントは処理完了というふうに判断して、ユーザーに結果を返して処理終了というふうになります。
ここまでの流れを1枚の簡単な図にすると、このような形になります。こういうふうに見ると、AIエージェントの仕組みというのは意外とシンプルなものになっているかなと思います。
ツール実行リスクへの対応
AIエージェントのリスクへの対応
ではここで、改めて、AIエージェントのリスクに対して、私たちがどのように対処することにしたのかを共有します。
意図しない処理が実行されるリスクについて
- そもそもリスクのあるツールを実行させないように対処しました。詳細はこのあと説明します。
コスト課題について
- まず小さく導入していくというところでコストを見ていくことにしました。
- また、AIエージェントを使って作業を効率化できる部分もあると思っており、それによって人が実施するよりもコストは減っていくと考えられますので、こちらは別途予算を確保して実施していく予定となっています。
モデル利用の制約について
- 最初に東京リージョンしか使えないというところがあったのですが、こちらについては別のAWSアカウントを作成して、海外リージョンを利用可能な状態に準備をしていきました。
- Bedrockがデータを保持しないというところがありますので、海外リージョンを使っていけないという課題についてもこちらで解消しています。
ツール実行のリスク
先ほどのAIエージェントの仕組みの図においては、この赤枠で囲まれた部分がリスクの箇所となります。
ここで実行されるツールというのは、AIエージェントによって異なっているのですが、多くのAIエージェントではBashを利用できてしまうのが一般的です。これによってrmなどのコマンドが実行できてしまうという課題が生まれるというところになります。
もしくは、最近であればMCPが利用可能になっているので、MCPの実行時にパラメータの一部にパスワードや、トークン情報などの機密情報が渡されてしまうことで、外部に流出してしまうなどのリスクが生まれるということになります。
個人利用では対策がいくつかある
ただ、これらの問題というのは、個人で使う場合において対策はいくつかあります。
例えばClaude Codeにおいては、ツール実行のリスクを軽減するためにsettings.jsonというのがありますので、そこで利用可能なツールを制限するということはできます。
また、Devコンテナを使うことでツールが実行されたとしても、影響を小さくするといった対策もあります。
ただ、これはあくまで個人が対策するものであって、組織として使うにあたっては、これを強制的に使ってほしいというところを課題感に思っていました。
コード生成AIエージェントを作る
ということで、私たちはコード生成用のエージェントを作ってみることにしました。
この画面のサンプルにおいては、少し分かりにくいかもしれないですが、上の方にbuild.gradleを参照して、どのようなライブラリを使っているか教えてという指示を与えているところです。エージェントは対象のファイルを読み取って使っているライブラリを回答しているという形になります。
ツール実行リスクの軽減
自作することがなぜツール実行のリスクを軽減につながるのかという話なのですが、一般的なAIエージェントでは、Bashなどのように汎用性の高いツールを用意していることがリスクにつながっているかなと思っています。
ここを私たちはファイル操作に限定してツールを作成してみましたというところです。かつ、相対パス以外のファイル操作を禁止するようにして、意図しない課題への対応を行っていたというところです。
これに対して「精度どうなの」という感覚かと思うのですが、簡単なソースコードの生成だけであれば、この程度のツールでも十分に動作します。
とはいえ自作には限界もある
ということで安全性を担保したのですが、でもやっぱり自作のAIエージェントには課題はあるかなというところです。
こちら課題の例なのですが、私たちはAIエージェントの開発だけを対応しているわけではないので、開発工数があまりない点であったり、MCPなどのトレンドへの追従だったり、UI周りがいけてない、ループの繰り返しで指示内容をAIが忘れるなど、Claude Codeとか、そういったもののAIエージェントと比較すると、やっぱり見劣りする部分が多くあったというところです。
ただ、こちらについては、当初から環境整備までのつなぎを想定していたというところです。ただ、想定よりも速いスピードでAIエージェントが進化していく中で、やっぱり一般的なAIエージェントを早く使いたいというふうに感じるようになってきました。
Claude Code Actionの登場
Claude Code Actionの導入
ちょうどClaude Code Actionがリリースされました。
私たちは、GitHub Enterprise Serverで開発をしていて、ActionsもEKS Self-hosted Runnerで、かつProxyを介して、ホワイトリスト形式でインターネットに接続しているのですが、これが意図しないツールの実行の課題に対しての一定のリスク回避になると判断しました。
例えば、フォルダがツールの実行で削除されてしまったとしても、コンテナの中の処理なので再起動すればよくなりますし、インターネット接続も許可されたドメイン以外はエラーになるというところです。
なので、こちらは私たちの組織で導入を判断して入れています。
下図は実際のClaude Code ActionによるPRレビューの様子です。SpringBoot 3.5へのアップグレードのレビューを依頼したところ、build.gradleの依存関係とバージョン変更を確認し、Javaコードの互換性と正規表現の扱い、AWSインフラ設定の変更、セキュリティとベストプラクティスの確認、各種依存性は最新と互換性を正規化するなど、詳細なチェックリストを提示してくれました。
さらに、私はClaude Code ActionがEnterprise Serverで使えるように対応もしました。
運用自動化のAIエージェントを作成
もう一つ、私たちはAIエージェントを作りました。運用自動化のAIエージェントです。
私たちのテスト環境には様々な運用課題がありまして、それが開発工数などを削る要因となっていました。例えば、私たちは全部で10個のテスト環境が存在しているのですが、1台のEC2に10環境すべて載せているみたいなサーバーがありまして、そこで定期的にOut Of Memory Errorが発生していました。
これまでですと、その都度サーバーに入って再起動していたのですが、これはAIエージェントを使って、この左の図にキャプチャがあるのですが、Slackでメッセージ一つで再起動が実施できるようになりました。
ここの図にイメージに貼ってある通り、マイページウェブというのがシステムの名前なのですが、「マイページウェブのUAT環境を再起動して」というだけで、AIエージェントが勝手に再起動してくれるという形を実現しました。
運用自動化のAIエージェントを作成（詳細）
処理自体はMCPで作っていて、Vercel MCP Adapterというのを使っているのですが、今回ご紹介したのはサーバーの再起動だけなのですが、エラーメッセージを見て原因調査をしたり、自動修復をしたりして拡張して、より高度なことを実現していく予定です。
今後やりたいこと
今後推進したいAIエージェント施策
最後、今後やりたいことになります。今大きく三つありまして、一つがdodaというプロダクトに対してAIを適用して、ユーザーに多くの価値を提供していきたいなと考えています。
もう一つは、ActionsでClaude Codeを使えるようになったのですが、今度はローカルでAIエージェントが使えるように環境を整備していきたいなと思っています。
最後がAIエージェントを利用して、実際に開発効率を上げていきたいというところと、その過程で開発組織の体制や、開発の進め方を見直していきたいと考えています。
AI Gatewayの導入
この環境づくりのところに関してだけもう少し補足します。
具体的な実現方法としては、AI Gatewayの導入を進めています。
AI Gatewayを入れることで、2つのポイントでツール実行に制御を加えることができます。
1つ目：AIエージェントが作成したプロンプトをチェック
- もし、このAI Gatewayに到達したタイミングで許可されていないツールがある場合、例えば許可されていないMCPがある場合には、そのツールをプロンプトから除外するみたいなところが実現できるというところです
2つ目：LLMからツールの実行指示が来た時のチェック
- もし危険なツールの実行指示があった場合に、エラーにしてAIエージェントにツールを実行させないということをして、リスク回避できると考えています
こちらは今月から来月にかけて私たちの開発組織で導入しようと思っていますので、もし実現できたらブログ投稿いたします。
成果と振り返り
最後に私たちの成果と振り返りです。
AIコードレビューなどのように現在も使われて効果が出たものもあれば、自作のコード生成ツールなどのように使われなくなったものもあります。
なので、成果としてイマイチだったものはあるのですが、振り返ると、その時にきちんとチャレンジして作った結果が後の成果で生きて、早期にキャッチアップできて対応できた要因と考えているので、環境の制約があって苦しんでいても、めげずに必要に応じて自分たちで作っていくことが後々生きてくるなと実感していますので、これからも学びを止めずに色々と手を動かしていきたいと考えています。
自作AIコード生成ツールからは「LLMの呼び出し方を理解できた」という学びが得られ、自作コード生成のAIエージェントからは「AIエージェントのつくり方を理解した」という知見が蓄積されました。
これらの知見は、その後のClaude Code Actionの導入、自作運用自動化のAIエージェント、そして今後予定されているプロダクトへのAI適用やAI Gatewayの導入へと活かされています。
まとめ
私たちは制約が多い環境ではありますが、新しい技術のキャッチアップによって回避策が見つかったので、もし同じような境遇の方がいらっしゃいましたら、参考になれば幸いです。
また、AIの技術の発展で作ったものが無駄になったこともありましたけれども、その過程で得た知見が生きていると考えていますので、ノウハウとかツールは今揃ってきていると思いますので、ぜひAIエージェントを使うだけではなくて、作ってみていただければと思います。
▼▼ ぜひ他登壇者の発表レポートもご覧ください！
