MCPから始めるAIエージェント開発 - POCから本番へのステップアップ手法

社内の業務フローや顧客サポートなどを効率化するため、AIエージェントへの注目が高まっています。しかしAIエージェントの開発や要件定義の知見は多いとはいえず、開発者やPMが自身で試行錯誤するしかないのが現状です。

この記事では、開発コストを減らし、実際に動かしながら仕様を調整していく進め方として、MCPサーバーでのPOC提供について提案します。具体例として、社内の日報作成を効率化するために Backlog API と Amazon Bedrock を活用した手法について紹介します。

AIエージェント開発の課題

社内で AI 活用に関するアンケートを実施したところ、予想外の発見がありました。開発ツールやコーディング系の悩みが多いと予測していましたが、実際には「開発以外のタスクを効率化したい」という要望が圧倒的に多数となりました。

背景を調査すると理由が明らかになりました。開発の効率化や AI 活用については、多くの開発者が自分ごととして捉え、すでに自発的に取り組んでいました。対照的に、1日数分から10分程度で終わるルーティンや事務作業については、効率化に取り組む時間も確保できないまま放置されているケースが目立ちました。

これらの小さな業務は短時間で完了するものの、集中力が途切れるなどの潜在的なデメリットを生み出します。小さな非効率が積み重なることにより、全体の生産性が低下していることが判明しました。

MCPを選択した理由

この課題を解決するための1つ目の取り組みとして、Backlog 連携による日報作成の自動化に着手しました。当初はBacklog APIを使って情報を収集するだけのLambda関数も検討しましたが、以下の理由からMCPを選択しました。

• MCPの機能を実務で検証したいという目的があった
• 単なるデータ列挙と実用的な日報原稿には大きな質的差異がある
• ローカル環境で簡単に動作確認ができる利便性がある
• ClaudeやCursorなどの固定課金サブスクを利用していれば追加コストなく試験運用が可能

特に開発効率の観点からは、MCPサーバーの利用によって「生成AIモデルの呼び出し部分」の開発が不要になることが大きなメリットでした。Backlogで特定ユーザーのアクティビティ情報を収集するMCPサーバーを構築すれば、その後の処理はMCPクライアント（Claude Desktopなど）が担当します。

実装プロセス

初期の実装段階で、単純にBacklog APIをプロキシするだけでは不十分であることが判明しました。「期限を延期しただけの変更」や「親課題の変更のような課題の整理」といった情報まですべて含めると、レポートが冗長になり実用性が損なわれます。

この問題に対応するため、情報を適切にフィルタリングする処理をMCPサーバーに実装しました。この改良により、日報に真に必要な情報のみを抽出することが可能になりました。

server.tool("list_backlog_daily_activities", {
  userId: z.number().describe("User id"),
  date: z.string().describe("Date"),
}, async ({ userId, date }) => {
  const backlogUserId = userId < 1 ? await backlog.getMyself().then(myself => myself.id) : userId;
  const service = new BacklogActivityService(backlog);
  const activities = await service.getMeaningfulActivities(backlogUserId, date);
  return {
    content: [{
      type: "text",
      text: JSON.stringify({
        ...activities,
        report: undefined
      })
    }]
  }
})

Claude Desktopで実行したところ、その日の作業内容をリストアップして整理する機能については概ね問題なく動作することを確認できました。社内でテスターを募集してMCPの普及活動を計画していましたが、残念ながら胃腸炎による一家全員の体調不良という事態が発生し、計画は延期となりました。

POCから本番環境への移行

活動が延期になった期間を活用して実装や動作を見直した結果、「スケジュールに余裕ができたので、定時に実行するバッチ処理として実装できないか」という発想が生まれました。この着想を受けて、AWS CDKを活用したLambda関数をCursorで実装することにしました。

ここでもAWS CDK MCPを活用して効率化を図ったことにより、実稼働1営業日という短期間でLambda実装を完成させることができました。AWS環境内で完結させるため、AIエンジンとしてはAmazon BedrockのNovaシリーズを採用しました。

Novaシリーズについては、以下のようにmodelIDの指定方法に特殊性があるため注意が必要です。

const command = new ConverseCommand({ 
    modelId: "apac.amazon.nova-pro-v1:0", 
    inferenceConfig: {
        maxTokens: 5000,
        temperature: 0.2,
        topP: 0.2,
    },
    messages: [
        {
        role: "user", 
        content: [
            {
                text: result.report
            }
        ]
        }
    ],
    system: [
        {
        text: `あなたはある開発者の秘書です。提出されたチケット管理ツールからのレポートを読み、日報を作成するのが業務です。
    レポートの内容をもとに、以下の項目に整理した日報を生成してください。

    ・業務内容 (Fact)
    ・改善したこと・解決したこと (Keep)
    ・問題点・課題 (Problem)
    ・次のアクション (Try)`
        }
    ]
});

この実装により、BacklogからのデータをAIで整理し、日報をBacklogチケットとして自動作成する仕組みが完成しました。

MCPを活用した段階的アプローチの利点

MCPサーバーから開発を始める利点は、「生成AIが安定した処理を行えるデータが生成できるかどうか」や「この連携や要件で適切に機能するか」を最小限のコストで検証できることにあります。

「MCPサーバーとして呼び出す作業が煩雑になってきた」あるいは「社内展開を検討すべき段階に来た」と判断したタイミングで、MCPサーバーで利用した実装をAWS Lambdaなどに移植してAIエージェントへ組み込むことができます。BedrockやClaudeはPlayground環境が提供されているため、MCPサーバーのレスポンスとプロンプトを使用して、実装前に動作検証ができることも大きな強みといえます。

これらの準備を整えた上で作業を開始すれば、実装作業の主眼は「APIの呼び出し順序とデータの受け渡し方法」および「AWS Lambdaが必要なリソースに適切にアクセスできる構成になっているか」の検証に絞られます。

結論

AIエージェント開発を一度に進めようとすると、考慮事項や学習事項が増大します。その結果、本来重視すべきユーザー体験や解決すべき課題が見落とされるリスクが生じます。

MCPサーバーとして、AIを意識せずに開発する段階から着手し、徐々にAIエージェントの挙動をイメージしながら構築していくアプローチは、開発コストを抑制しつつ、実用的なAIエージェントを構築するのに効果的な方法です。

MCPを活用することで、小規模な取り組みから実用的なAIエージェントの開発へとステップアップしていくことが可能になります。