LayerX AIエージェント ブログリレー 40日目の記事です。 昨日は ＠yuya_presto さんの「Chrome拡張だけでVercel AI SDKからブラウザを操作する browser-agent-bridge」でした！
こんにちは。すべての経済活動をデジタル化したいmichiru_daです。
私はコーディング未経験の営業上がりのプロダクトマネージャーで、普段自分でコードを書くことはありません。 ですが今回は大エージェント時代に乗っかり、Claude Agent SDKを利用して自分の業務を効率化するAIエージェントを作ってみました。
本記事では、普段エンジニアリングを行わない非エンジニアの目線で、実際の業務ユースケースに沿ってAIエージェントを実装した学びを共有します。エージェント実装そのものの有益なtipsなどは含まれないので、ご了承ください。
この記事の対象読者
- 自チームのPMもエージェントを触った方がいいと考えているエンジニアの方
- 「AIエージェント、触らないとわからない気がするが、何から始めれば…」と悩むPMの方
- 「AIはプロ（エンジニア）に任せよう」と割り切っているPMの方
目次
やったこと
1. 何を作ったのか
(1)背景と課題
弊社で提供している稟議サービス「バクラク申請・経費精算」では、申請時にAIがリアルタイムで承認可否を判断する「AI申請レビュー」というAIエージェントを利用できます。
このサービスを利用いただく際には、お客様の既存の社内運用ルールをバクラクの仕様上実現可能な設定に翻訳した上で、現状のAI申請レビューで精度高くレビュー可能かを判定し、実現イメージを擦り合わせるプロセスを挟んでいます。
しかし、お客様が独自に運用されているルールを、バクラク専用のルールに落とし込む作業は、お客様・社内の営業担当にとって工数負担が発生する状態になっています。
(2)作ったもの：お客様承認ルールの翻訳AIエージェント
そこで、お客様には最終チェックだけしていただく 状態を目指して開発したのが以下のAIエージェントです。
- ユーザー（バクラク担当者）：お客様の運用ルールを自然言語でそのまま入力します。
- AIエージェント：
- (a) 入力された自然言語を、バクラクのマスタや項目を使った「システム用ルール」に変換します。
- (b) (a)で生成したルールについて、本番環境で動作検証済みのAI申請レビューのルール一覧に近いものがあるかをRAGで検索・評価します。
- ユーザー（バクラク担当者）：エージェントが出力した「ルール案」と「評価結果」を確認し、バクラクでの実現可否・AI申請レビューでの対応可否を判断します。
(3)システム構成の概要
システムは、大きく分けて3つの要素で構成されています。
ユーザーインターフェース (UI) : ユーザーが指示を出し、エージェントが生成したルール案や、類似ルールの検索結果（例: 類似度89%の検証済ルール）を確認する画面です。ここで人間が「OK / NG / 編集 / この類似ルールを使う」といったレビューを行います。
AIエージェントエンジン (Claude Agent SDK) : システムプロンプトで定義された複数ステップの指示書に従い、必要なツールを自律的に呼び出しながらタスク（ルールの生成・検索）を実行します。
ツール群 (Tools) : エージェントの手足となる機能群です。今回は4つのToolを準備しました。
- ①フィールド定義取得: 利用可能なDB項目やマスタの一覧を取得します。
- ②フィールド推薦: 自然言語でインプットされた顧客の運用ルールを解釈し、①から最適な項目を推薦します。
- ③ルール生成: ②をもとに、バクラクで設定できるの自然言語ルールを生成します。
- ④類似ルール検索: ③で生成したルールが、AIレビューの検証済みルールと似ているかRAGで検索します。
2. 非エンジニアなりに工夫した3つのポイント
AIエージェントの精度を上げ、実用的にするために工夫したのは3点です。
(1) "利用可能な項目"をToolで外部から与える
当初、AI申請レビューのガイドラインだけをLLMに渡したところ、サービス上に存在しないマスタや項目を勝手に生成してルールを生成する事象が発生しました。
そこで、利用可能なマスタや項目のリストをToolとして定義し、この中からデータを使ってルールを生成するように指示することで、アウトプットの選択肢をツールで制限でき精度を安定させました。
シンプルな変更ではありましたが、「AIの出力を決定論的にする工夫」とはこういうものを指すのか！と学びになりました。
(2) 要所で人間がレビューを挟む
エージェントがどのフィールド（項目）を使うか、どの演算子を使うか、といった重要な分岐点では、必ず人間が「決定」するHITL(Human-in-the-Loop)のステップを挟みました。これにより、エージェントが誤った解釈のままルール生成を進めてしまうことを防いでいます。（ただし、ルールが多いと毎回確認するのは大変なので、体験設計の工夫は必要です。）
(3) 対象ルールと動作検証済ルールの「構造」が似ているかをRAGで検索する
また、今回のユースケース特有ですが、「具体的な値を含めて似ているルール」ではなく「構造が似ているルール」が存在するかをチェックしたい背景がありました。
実現したかったこと:
- ルールA: 「タクシー代 であれば フィールドA に利用目的を記載する」
- ルールB: 「リムジンバス代 であれば フィールドA に利用目的を記載する」
→ この2つを「同じ構造のルール」としてみなしたい。
そのために、RAGで検索するベクトルデータベースを構築する際、LLMで以下のように変換したルールも一緒に登録しました。
変数化されたルール: 「
{内訳}であれば{フィールドA}に利用目的を記載する」
検索クエリ（新しく生成されたルール）も同様に変数化してから検索することで、具体の値は違っても、構造的に近いルールを見つけることを可能にしました。
3. 実装までの道のり（と挫折）
非エンジニアの私が、どうやってここまでたどり着いたかの道のりは以下です。
(1) 書籍『LangChainとLangGraphによるRAG・AIエージェント［実践］入門』の写経（貢献度: 20%）
こちらを読んでコードを写経しました。経理出身の当社のプロダクトマネージャーが本書をもとに実際に手を動かして実装していたことに感化されて、とりあえず真似してみたのがきっかけです。
RAGを動かすところまでは写経しましたが、実際にはPythonとLangChainの知識が必要で、かなり大変でした。完璧に理解するには時間がかかりすぎるので、雰囲気がわかったらどんどん次に進むことにしていましたが、初心者にありがちなライブラリのバージョン問題にも直面し、書籍のコードを再現しても手元で動かないという事象も多発しました。
(2) 書籍『現場で活用するためのAIエージェント実践入門』を読む（貢献度: 20%）
次に、当社のMLエンジニアに勧められたこの本を読みました。1〜2章は聞いたことある概念がなんとなくわかるようになる構成で、読みやすかったです。
また、3章以降は実装事例も豊富なので、とりあえず手元で実行して動きを見る、あるいはChatGPTにエージェント関係ない部分を解説してもらう形で読み進めていき、toolの定義までは無事に読み進めることができました。
ただ、4章以降でLangGraphを使ったエージェント実装に入ったところで、内容が私の理解可能なコンテキストサイズを完全に超えてしまい、読解を挫折しました。
(3) 社内のエンジニアに助けてもらう（貢献度: 60%）
結局、これが最大の要因です。上記1と2の書籍を実践する時点から、ChatGPTで解決できない初心者質問（バージョン問題など）は、すべて社内のエンジニアに相談していました。その過程で、Toolsのアイディアなども沢山アドバイスをもらえました。
書籍での挫折の通り、0から1でエージェントを実装する難易度が高すぎたため、最終的には、厚意でClaude Agent SDKをベースにしたシンプルなエージェントの雛形コードを書いてもらい、自分はそれを実ユースケースに変換していくことで、今回紹介したエージェントを動かすことができました。
手を動かしたからこそ得られた学び
手を動かして自分が欲しいAIエージェントを作ることで圧倒的に学びの解像度が上がるのが、今回の取り組みの大きな発見でした。 自分としても驚きがあったのは以下の3点です。
1. 素のLLMは思ったより何も「よしなに」やってくれない
初心者すぎますが、素のLLMが「よしなに」動くためには、お膳立てがたくさん必要だと実感しました。普段触るChatGPTやGeminiの多くが、既によしなにツールを呼び出すAIエージェントです。LLMはそのままだと「今日」の日付すらわかりませんし、会話内容もこちらで処理を書かないと忘れてしまいます。楽しいプロンプトチューニングに至る以前に、整備すべきことが多いと知りました。
2. エージェントは「自由にさせない」ようにしないと価値が出せない
特にtoBサービスでは「LLMにアウトプットはさせるが、よしななアウトプットはさせない」重要性を再認識しました。
実装前は、AIエージェントはToolsもプロンプトで定義したり、とにかくHITLで決定論的にするようなイメージを持っていましたが、実際のToolsは明確に関数を定義する必要があります。
自分が欲しいユースケースに対してAIエージェントを実装し、何も制御しない状態の出力を見て初めて「AIの非決定論的な出力を決定論的なアウトプットに変換したり制御する工夫が必要だ」と腹落ち できました。
3. AIやエージェントは手段にすぎないが、なぜか手段ありきになりがち
今回、構造が似ているルールの取得はRAGで行いましたが、この部分は別にRAGでなくても良いと考えています。
実際、エンジニアに質問する中で、ルールにタグ付けを行い、特定のマスタ同士を利用して構成されたルールを検索する方向性も議論しましたが、この時に自分自身RAGのhowに引っ張られているなーという気づきがありました。
改めて、PMはいつでも「AIじゃなくてもこれで十分だな」を冷静に評価することが大事だと感じます。
「理論上わかった」を超えた先に、爆速な価値のデリバリーがある
上記の3つは紹介した参考書籍でもちろん触れられていましたが、本を読んだだけではきっと「ふーん」で終わっていたでしょう。
現在も「餅は餅屋」という感覚は変わりませんが、AIエージェントの実装において、「理論上わかる」と「実際このように対応する」は想像以上に隔たりがありました。
普段コーディング経験がないPMであっても、シンプルなエージェントでも一度作っておくと、エンジニアとのコミュニケーションが格段に早くなると感じます。
早く会話し、早く意思決定し、早くリリースできるようになれば、Agentの優位性構築・お客様への高速な価値提供にも繋がるはずです。
プロダクトのCoreとWhyを決めるのがPMの役割というのは変わらずも、高い品質で価値を高速にデリバリーするhowの解像度を持ち続けるために、あえて一度自ら手を動かすのは良いアプローチかもしれないと感じます。
非エンジニアでも、本当に作れる?
非エンジニアがエージェントを作ろうとする時は、エンジニアのヘルプが本当に不可欠です。
私自身、ChatGPTもClaude Codeももちろん使いまくりましたが、エージェントが動くまでには、そもそもの体系的なPythonの理解・コード管理の理解・AI周りのライブラリの知識など、必要となるスキルや知識が非常に多いです。 どうしても自分だけで取り組むのはしんどく、無理があると感じます。（実際『現場で活用するためのAIエージェント実践入門』は挫折しました。）
今回は身近に質問できるエンジニアの方がいたので、途中で諦めずに動かすところまで辿り着けましたが、どこでも再現できるわけではないなあという難しさも感じます。
理想としては、PMはエンジニアに全てを任せきりにするのではなく、もっと並走できるといいなと思います。 そのためにも、 中長期の投資として、エンジニアがPMや非エンジニアメンバーをサポートできる環境を作ることで、組織全体で、AIを使った顧客価値の提供スピードが高められるように思いました。
2025年10月時点ではエージェントを使ったプロダクト価値の創出はまだ不確実性が高いテーマだと思います。ぜひ、役割を超え、開発チーム全員でAIエージェントの解像度を上げるアクションを行ってみてはいかがでしょうか。
