はじめに とあるプロジェクトで手動運用業務をAIを活用して効率化したいという背景で参入、すでに複数の自動化ツールを作成しました その経緯で学んだことをまとめてみます。 本記事のテーマ AIを活用した業務効率化を担当することになり、本格的に生成AIを学び実践してきました。 その中で最も重要だと感じたのは、「AIが回答しやすい・考えやすい環境を作ること」 プロンプトの工夫ももちろん大切ですが、求めている回答を引き出すには、前提となる「潤沢な背景情報」が不可欠 もしAIに渡す情報が足りているか不安なときは、「今の指示で足りない情報はありますか？」とAI自身に聞いてみるのも1つの手だと思

はじめに # 本ページは「AIエージェントとシステムをつなぐMCP入門」の続編です。 今回は、プロンプトについて説明します。 MCPのプロンプトは、MCPクライアント向けにテンプレート化されたメッセージやワークフローを提供する機能です。 生成指示やツールの利用順序を定義したワークフローなど、テンプレート化して再利用したい場合に有効です。 本記事で掲載しているコードは こちら で公開しています。 --> シリーズ目次 連載：AIエージェントとシステムをつなぐMCP入門 イントロダクション stdio実装編 StreamableHTTPステートレス実装編 StreamableHTTPステートフル実装編 プロンプト編（本ページ） 今回使用するライブラリなど # npm@11.11.1 node@22.22.0 typescript@6.0.3 @modelcontextprotocol/sdk@1.29.0 zod@4.3.6 使用例 # 定形タスクのテンプレート化: コード生成やレビューなど利用頻度の高い指示をテンプレート化することで、クライアント側の指示作成を省略できます ペルソナやルールの適用: 役割や出力形式の制約をコンテキストとして適用します ワークフローのテンプレート化: ツールの利用順序などを定義して一連の流れをガイドします 実装サンプル # コードの全体は こちら をご覧ください。 定形タスクのテンプレート化 # 定形タスクであるレビュー指示をテンプレート化した実装例です。 最近は省略されがちですが、サンプルなので役割も明示しています。 argsSchema（引数スキーマ）: プロンプトの変数部分を定義するもの messages: roleとcontentで構成されるメッセージ配列 role: メッセージのスピーカーを示す識別子で、user/assistantのいずれかを設定します user（ユーザー）: 人間からの入力を表します。ここにAIへの指示（プロンプト本文）を記述します。 assistant（アシスタント）: AIからの返答を表します。 --> プロンプトの指示だけではレスポンスの形式がブレてしまう場合 出力形式の「見本（Few-shot）」をあらかじめAI自身の返答として配置しておくことで、精度の高い結果を引き出せます。 content: メッセージ本体。サンプルはテキストのみですが、バイナリ（画像、音声、埋め込みリソース）も扱えます。 text（テキスト）: プレーンテキストのメッセージで、自然言語のやりとりで一般的に使用されるタイプ image（画像）: 視覚的な情報を含むメッセージ audio（音声）: 音声情報を含むメッセージ resource（埋め込みリソース）: サーバーのリソース（ドキュメント、コードサンプルなど）を会話に組み込む。 --> バイナリを扱う場合 Base64でエンコードし、適切なMIMEタイプの設定が必要です。 // プロンプト：コードレビュー指示をテンプレート化 server.registerPrompt( "code-review-prompt", { title: "code-review-prompt", description: "コードレビュー指示", // 引数スキーマの定義：MCP InspectorなどのMCPクライアントのUIで入力フォームとして表示され、サーバー側の関数に渡されます。 argsSchema: { specPath: z.string().describe("仕様書パス"), codePath: z.string().describe("対象コードパス"), }, }, async ({ specPath, codePath }) => { return { messages: [ // user: プロンプト本文 { role: "user", content: { type: "text", // 実務ではもっと細かい指示が必要になりますが、行数を抑えるため最小限に留めています text: [ "コードレビュー指示", "あなたはNode.js/TypeScriptのバックエンド開発スペシャリストです。", "* 優先観点: 仕様整合性、例外設計、認可制御、トランザクション制御、性能、保守性、セキュリティ。", "* 禁止: 推測で仕様補完しない。根拠のない断定をしない。", "* 指摘の重大度: High(必須)/Medium(基本的に対応)/Low(できるだけ対応)を付ける。", "* 指摘は「問題」「対象個所」「修正案」を1行で示す。", "* 出力は最大10件、重複指摘は統合する。", "* 改善コードが必要なら最小差分で提案する。", `* 仕様書パス: ${specPath}`, `* 対象コードパス: ${codePath}`, ].join("\n"), }, }, // assistant: 見本 { role: "assistant", content: { type: "text", text: ["（コードレビュー指摘の出力例）", "1. High: [問題] 仕様に記載のないAPIエンドポイントが存在する。 [対象個所] src/api/user.tsのgetUser関数。 [修正案] 不要なエンドポイントなら削除、仕様が古いなら更新して整合させる。", // omit ].join("\n")}, }, ], }; }, ); 動作確認（MCP Inspector） ワークフローのテンプレート化 # ツールの実行順序をテンプレート化した実装例です。 // プロンプト: 指示やワークフローをテンプレート化。 server.registerPrompt( "inventory-check-workflow", { title: "inventory-check-workflow", description: "在庫確認ワークフロー", argsSchema: { orderNo: z.string().describe("受注番号"), }, }, async ({ orderNo }) => { const prompt = [ "在庫確認ワークフロー", `1. tools/callでget-orderを実行してください。（引数 orderNo: "${orderNo}"）`, "2. tools/callでcheck-attached-inventoryを実行してください。（引数: orderId: 1のレスポンスのorderId, quantity: 1のレスポンスのquantityの合計）", "3. 2のレスポンスのavailableがtrueなら「在庫引当済み」、falseなら「在庫不足」と返してください。", ].join("\n") return {messages: [{role: "user", content: {type: "text", text: prompt,}}]}; }, ); server.registerTool( "get-order", // omit: 今回は固定値を返すだけの実装にしています ); server.registerTool( "check-attached-inventory", // omit: 今回は固定値を返すだけの実装にしています ); 動作確認（MCP Inspector） プロンプトの利用（VS Code） 実際にプロンプトを使ってツールの実行を指示して動作を確認。 プロンプトで指示した順にツールを実行し、結果も指示した通りに返されました。 まとめ # プロンプトは、定形タスクを標準化したい場面で効果を発揮します。 プロンプト内でツールの呼び出し順序を指示し、同じサーバー内にそのツールを registerTool で用意しておくと、LLMが指示にしたがって自律的にツールを呼び出し、一連の作業を自動完結できます。 次編ではリソースを扱います。

はじめに こんにちは！ タイミーでPlatform Engineerをしている @MoneyForest です。 2026年6月9日〜10日にニューヨークで開催された Datadog の年次カンファレンス DASH 2026 に参加してきました。弊社からは、MLOpsエンジニアの斎藤が「 How Timee Delivers Day 1 Production Ready LLM Features 」というタイトルで登壇していました。 本記事では、Keynote の全体像、タイミーの登壇セッション、そして Fireside Chat から得たメッセージについてお届けします。 DASH 2026 の全体像 公式のKeynoteの記事 にあるように、まさに「Datadog enables teams to build better with AI」といった内容でした。AI がコードを書くスピードは劇的に速くなったが、それを安全に運用するためのループも同じスピードで回らなければ意味がない。この課題に対し、Datadog は Bits AI というAIエージェント群を中核に据えた新製品群を提示しました。 Keynote Keynote で発表された新プロダクトは、AIエージェントによってループを閉じ、開発を高速化するためのものでした。ループは大きくOps・Dev・AI Agent の3つの軸で整理できます。 全発表の詳細は Datadog 公式の記事 に網羅されているので、ここではループごとの要点に絞って紹介します。 Ops ループ （Detect → Investigate → Remediate） 従来人間が手作業で回していた検知・調査・修復のループを Bits AI で自動化する軸です。 Bits Detection （Preview）はサービストポロジーやデプロイ履歴から何が重要かを推測し、本番が赤くなりそうなときだけ発火するモニターを自動で作成・維持します。大量のフレーキーなモニターリストを置き換えるものです。 Bits Memories （Preview）は Slack でのインシデント対応やポストモーテムから運用上の教訓を学習し、将来の調査に適用します。 Bits Remediation （Preview）は根本原因に対して kubectl コマンド実行やコード修正 PR 作成まで自律的に行います。 Bits Infrastructure Operations （Preview）は OOMKilled や証明書期限切れといった日常的なインフラ問題を自動で検知・修復します。 Dev ループ （Code → Deliver → Evaluate） AI コーディングエージェントが加速する開発スピードに対して、リリースの信頼性を追いつかせる軸です。 Bits Code （GA）は Datadog が問題を検出したあらゆる場所（Error Tracking、APM、Code Security 等）から、本番テレメトリを根拠にした修正 PR を生成します。 Bits Release （Preview）は PR の意図を理解し、「新機能が動くか」「リグレッションがないか」の両面でバリデーションプランを自動生成するリリース検証エージェントです。 Bits Testing Agent （Preview）は URL や自然言語のゴール（例：「黒いサングラスを購入して」）からアプリを自律探索し、セルフヒーリングなテストスイートを生成します。 Agent Console （GA）は Copilot / Cursor / Claude Code 等のコーディングエージェントの利用状況を組織横断で可視化し、非効率なパターンの検出やコストアラートを提供します。 AI Agent ループ （Observe → Evaluate → Experiment → Ship） AI エージェント自体を本番で運用・改善するためのループです。 Agent Observability Patterns （Preview）は、本番の LLM トレースを行動パターンに自動分類します。デモでは15,000件のトレースから想定外の「coordination」パターンが $20,000 のコストを生んでいることを発見し、根本原因分析から修正・検証まで一気通貫で行っていました。 Bits Evals （Preview）はトレース・データセット・プロンプトバージョンを横断して仮説検証やプロンプト改善を自動化します。 Data Observability （GA）はデータパイプライン全体のリネージと異常検知を担います。 Infinite Cardinality Metrics （GA）は課金モデルをカーディナリティベースからメトリクス名＋データボリュームベースに変更し、高カーディナリティ環境でのコスト予測可能性を大幅に向上させます。 その他 AI Guard （Limited Availability）はカスタムエージェントとコーディングエージェント双方の入出力をインターセプトし、プロンプトインジェクションやツール悪用をリアルタイムでブロックします。 Runtime Prioritization Engine （Preview）は16,000件の CVE から本番で悪用可能な9件に自動で絞り込み、 Security Analyst （GA）がセキュリティ調査を自動化します。 Journey Monitoring （Preview）：Synthetics・RUM・Product Analytics を統合し、ユーザージャーニー単位で可用性・パフォーマンス・コンバージョン率を一つのビューで可視化。「CPU が高い」ではなく「その CPU 高騰でコンバージョンが落ちているか」を見る、ビジネスインパクトへの引き上げが狙い Federated Logs （Preview）：Log Explorer から離れずに Databricks 等の外部ストレージを横断クエリ Bits Database Optimization ：LLM 生成のクエリ最適化案をシミュレート DB で検証してから PR 化。デモでは500クエリから検証済み30件に絞り、ノイズを9割削減 タイミーの登壇：How Timee Delivers Day 1 Production Ready LLM Features dash.datadoghq.com speakerdeck.com 弊社 MLOps エンジニアの斎藤が、タイミーにおける LLM 機能のプロダクション対応と LLM Gateway の構築について発表しました。内容について要約して紹介します。 背景 タイミーでは LLM がワーカー・クライアント双方の体験を向上させる重要な要素になっています。求人票の自動生成をはじめ、多くのストリームアラインドチームが独立して LLM 機能を活用しており、MLOpsエンジニアがその基盤を支えています。 チェックリストの誕生 最初のプロダクション導入では、LLM の不安定さ（タイムアウト、レイテンシスパイク、レートリミット）を想定した設計を行い、Vertex AI をプラットフォームとして採用しました。この経験から、LLM 機能に求められるプロダクション水準を定義した Production Readiness Checklist を策定しました。一般的なプロダクションの品質基準に加え、LLM 固有のシグナル（フォールバック、モデルレイテンシ、コスト制御など）をカバーするものです。 障害による転機 求人票生成機能の導入後、同一プロバイダー起因で2つの LLM 機能が同時にダウンする障害が発生しました。チェックリスト・モニタリング・ゲートウェイはそれぞれ存在していたものの、採用するかは各チームに依存していたことが根本原因でした。 また、高いスピードで価値を届けるという当然の行動をしていた中で、3人の ML プラットフォームチームが全チームに基準を強制するのは物理的に不可能だったのです。 解決策：LLM Gateway この障害を転機に、全 LLM 呼び出しの共通エントリーポイントとして LLM Gateway を導入しました。Cloud Run 上に構築され、複数の LLM プロバイダーを抽象化しています。 ゲートウェイが提供する価値は3つです。 自由な探索：プロダクトチームがセットアップのオーバーヘッドなしにプロンプトやユースケースを試せる 可観測性：全呼び出しにチーム・機能・環境のメタデータが付与され、トレース・レイテンシ・エラー・フォールバックが一箇所で見える ガバナンス：コスト・使用量・レートリミット・安全性が自動的に強制される これにより、チェックリスト（期待値を定義）× モニタリング（コンプライアンスのエビデンス）× ゲートウェイ（パスの強制）が統一化され、すべてのチームが恩恵を得られる状態になりました。 このセッションは「成功事例ではなく、何が壊れ、何を学び、何ができるかの話」という齋藤の言葉通り、実践的な知見が詰まった内容でした。 Fireside Chat OpenAI や Vercel の幹部を招いた Fireside Chat （対談）が非常に印象的でした。それぞれの視点からエージェント時代のソフトウェア開発について語られましたが、共通するメッセージが浮かび上がってきました。 The New Shape of Engineering（Fireside Chat with Datadog CTO Alexis Lê-Quôc and OpenAI Head of Product and Platform Thibault Sottiaux ） dash.datadoghq.com OpenAI で Codex と API Enterprise を率いる Thibaut との対談では、エージェントが組織にもたらす変化が語られました。 特に印象的だったのは、可観測性の役割が根本的に変わるという点です。エージェントの生産性が人間のレビュー能力を超えるにつれ、「すべてのコードをレビューするのか？」という問いに直面します。システム開発は、コードを一行ずつレビューするのではなく、「症状と振る舞い」で監視する、つまり医者が患者を診断するようなアプローチになるというビジョンが語られました。 また、OpenAI 社内ではフォンブースを使っている人の大半が会議ではなく AI と話していたというエピソードや、Thibaut 自身の Codex の使い方がコーディングから情報の統合と組織の把握へシフトしたという話も、エージェント時代の働き方を象徴していました。 エージェントを正しく使うヒントとして、「生産性の幻想を避ける」（並行して動かしていても、本当に意味のある問題に取り組んでいるか？）と「良い状態を説明する」（同僚に期待値を説明するように、エージェントにも伝えること）が挙げられていたのも実践的でした。 Fireside Chat with Datadog CPO Yanbing Li and Vercel CPO Tom Occhino dash.datadoghq.com Vercel CPO の Tom Occhino との対談では、「意図と実装の距離がほぼゼロに縮まった」という時代認識から出発し、プロダクト開発の変革が議論されました。 特に印象的だったのは、仕事を「2つの波長」として捉える考え方です。 Long Wavelength（基盤作業）：コアプラットフォームの品質・信頼性・セキュリティを高める作業。AI を使ってプロセスを加速しても、既存の検証・可観測性・レビューはすべて残る Short Wavelength（グリーンフィールド）：誰も依存していない新規領域。AI をエンドツーエンドで使ってどんどんシップする 両方の組み合わせが大事であること、そして Long Wavelength 自体を短くしていくこと、つまりリリースエンジニアリングのエージェント化が次の挑戦として語られていました。 共通メッセージ 両セッションは全く別物ですが、かなり共通する点が多かったのが印象的でした。 「作ること」は安く速くなり、人間の価値は"何を・どう良くするか"の定義に移る OpenAI（Thibaut / The New Shape of Engineering）：Thibaut は「良い状態を説明せよ」と語りました。実装が安くなったぶん、エージェントに何を期待するのかを伝えないと、エージェントは勝手に仮定を置いてしまう。難しいプロジェクトの期待値を同僚に説明するのと同じように、成功基準と検証方法を明示することが結果を大きく左右する。 Vercel（Tom / Fireside Chat）：Tom は「意図と実装の距離がほぼゼロに縮まった」という時代背景からセッションを始めました。だからこそ PM のコア業務である成功の定義、明確な問題設定、顧客理解はなくなるどころか重要性を増す。仕様が明確であるほどコーディングエージェントの出力は良くなるため。 本番・検証・信頼は"無料ではない" OpenAI：Thibaut は、OpenAIのメインエージェントの全アクションを"元の意図"に照らして検証する Guardian（デュアルエージェント安全システム）を紹介しました。そしてAIエージェントへの信頼は一足飛びには得られない。テストとログへ惜しみなく投資し、実績を積み重ねることで漸進的に築かれていくものだと語りました。 Vercel：Tom は「ソフトウェアの構築はほぼ無料でも、本番は絶対に無料ではない」と強調しました。基盤となる作業（Long Wavelength）では、AI でプロセスを加速しても、可観測性・既存システムへの統合・人間によるレビューはすべて残る、と。 可観測性が検証の中心になる OpenAI：Thibaut は、AIエージェントの生産性が人間のレビュー能力を超えていく中で「すべてのコードをレビューするのか？」と問いを投げかけ、システムは医者が患者を診断するように「症状と振る舞い」で監視する時代になると語りました。過去に発火したアラートを分析してノイズを減らす、アラートのトリアージ自体もエージェントが担い始めています。 Vercel：Tom がユースケースで示したのは、本番から得たインサイトでフィードバックループを閉じる「AIエージェント型インフラ」でした。コアのバイタルを常時監視し、リグレッションが起きれば原因を二分探索し、修正もしくはリバートの PR を自動で出す。コードを一行ずつ追うのではなく、本番の振る舞いから全体の健全性を捉える方向に進んでいます。 まとめ DASH 2026 を通じて感じたのは、「検証、品質、安全性の評価を、個人の規律ではなく経路（path）に作り込む」という考え方が、発表全体を貫いていたことです。 例えばBits Release はリリース検証を、AI Guard はセキュリティ評価を、呼び出し経路に強制的に組み込みます。 この時代におけるプラットフォームエンジニアリングの仕事は基準そのものを作ることではなく、基準が自動で適用される経路（基盤）を作ることだと思いました。