本記事は 春のスキルアップ応援フェア2026 4/25付の記事です 。 こんにちは。Masedatiです。 私はLT（ライトニングトーク）が好きですが、スライド作成にもついつい時間をかけてしまいます。 最近登壇や講義活動が多く、いつの間にか1日が終わっていることもしばしばです。 そこで、今回ご紹介するものは、そんなスライド作成の悩みを解決してくれるツール「 spec-driven-presentation-maker 」です。 spec-driven-presentation-makerとは 「spec-driven-presentation-maker」は、AWS公式のサンプルリポジトリで公開されているプレゼンテーション作成ツールキットです。 仕様駆動開発の考え方をプレゼン作成に応用したもので、「何を伝えるか」を仕様として設計し、 生成AIがテンプレートに沿って自動的にスライドを作成 してくれます。 Spec-Driven Presentation Maker — 伝えたいことを先に設計し、スライド構築は AI に任せる | Amazon Web Services Spec-Driven Presentation Maker は、「何を伝えるか」を先に設計し、スライドの構築を AI に委ねるオープンソースのサンプル実装です。本記事では、仕様駆動アプローチの考え方と、AWS 環境への導入方法をご紹介しま... aws.amazon.com Layer1~4まで定義されており、利用規模や用途に応じて、アーキテクチャを選ぶことができます。 レイヤー 用途 必要なもの Layer1：スキル（エンジン） プレゼン生成、プレゼンテンプレート解析、レイアウト最適化など、PC上でPythonスクリプトとして使います。 Python, uv Layer2：ローカルMCPサーバー Layer1をMCPプロトコル化したものです。 KiroやVS Codeなど任意のMCPクライアントから「プレゼン作って」と命令するだけで使えます。 Python, uv Layer3：リモートMCPサーバー AWSにデプロイして、MCPサーバを共有できるようになります。 AWSアカウント, CDK Layer4：エージェント + Web UI Webブラウザからチャット画面でプレゼンを作れるようになります。 AWSアカウント, CDK 今回私は、Kiroでプレゼン作成を支援してほしいため、 Layer2を構築してみようと思います。 やってみた 公式ドキュメントをもとに構築を行います。 sample-spec-driven-presentation-maker/docs/ja/getting-started.md at main · aws-samples/sample-spec-driven-presentation-maker Contribute to aws-samples/sample-spec-driven-presentation-maker development by creating an account on GitHub. github.com Layer2の構築 リポジトリのクローン リポジトリをクローンします。 git clone https://github.com/aws-samples/sample-spec-driven-presentation-maker.git サーバーの起動 Layer2をセットアップするためのフォルダは「mcp-local」です。 cd msp-local uv sync uv run python server.py uv syncでやっていること msp-localフォルダ配下にある pyproject.tomlを読み取って、必要なライブラリを一括インストールします。 server.pyでやっていること FastMCP というライブラリを使って、MCPサーバーを作成します。 Layer2でのMCPツールは以下17個です。 ツール 役割 init_presentation プレゼンの作業フォルダを作成 analyze_template PPTXテンプレートのレイアウト・色・フォントを解析 generate_pptx JSONからPPTXファイルを生成 get_preview スライドのPNGプレビューを生成 measure_slides テキストがはみ出していないか計測 search_assets アイコン・画像をキーワード検索 list_templates skill/templates/ 内の .pptx ファイル名一覧を返す list_asset_sources 利用可能なアセットソースの名前、件数、説明の一覧を返す list_styles デザインスタイルの名前と説明の一覧を返す read_examples デザインパターン・コンポーネントの例を読み取る list_workflows references/workflows/ 内のワークフロー文書の名前と説明の一覧を返す read_workflows 指定したワークフロー文書の内容を返す list_guides references/guides/ 内のガイド文書の名前と説明の一覧を返す read_guides 指定したガイド文書の内容を返す code_to_slide ソースコードをシンタックスハイライト付きのスライド要素JSONに変換する。 pptx_to_json 既存のPPTXファイルをJSON表現に逆変換する grid CSS Grid風の仕様から要素の配置座標を計算する server.py は標準入出力で通信するMCPサーバーなので、起動すると何も表示されずに入力待ちの状態になります。 ここでrunするとターミナルが固まっているように見えますが、裏でMCPクライアントからの接続を待っています。 ここでは動作確認のため、エラーがなければCtrl + C で停止してください。 後続手順でKiroなどのMCP設定に登録すれば、MCPクライアントが自動で起動・接続してくれます。 MCPクライアントの設定 あとはKiroのMCP設定ファイルに以下を追加するだけです。 なお、mcp-localのパスだけ変更する必要があります。 {     "mcpServers": {         "spec-driven-presentation-maker": {             "command": "uv",           "args": [               "run",               "--directory",               "/Users/hoge/sample-spec-driven-presentation-maker/mcp-local",               "python",                 "server.py"           ]       }   } } 他のMCPと同じように認識してくれました。 プレゼンテーションを作って 「プレゼンテーションを作って」と命令すると、テーマ・対象者などのヒアリングがスタートします。 さっそく、このツールを使って「新卒入社向けの弊社紹介スライド」を作成してみましょう。 情報が集まると、各MCPツールを使ってプレゼンテーションを作成してくれます。 特筆すべきは、デザインパターンの情報取得です。これにより、既存のプレゼンテーションデザインを読み込んでくれます。 つまり、 各社独自のテンプレートがすでにあれば、そのデザインやトーンを維持したままスライドを生成してくれることができるのです。 （今回は、デフォルトで用意されているelegant-darkデザインを採用しています） できたプレゼンテーション 作成してくれたプレゼンテーションの一部はこちらです。 特に指定していないですが、いい感じのAgendaはもちろん、デザインや配置のバランスがとれた美しいスライドを作ってくれています。 このツールの優れた点は、各パーツがテキストボックスや図形として独立して作成されることです。 画像として出力されるわけではないため、生成した後のデザイン変更や微調整も思いのままに行えます。  

複数ステップの処理を自律的に行うことで注目される生成AIエージェントについて、LangChainのフレームワーク「LangGraph」を用いた実装初めの一歩を解説します。LangGraphは処理をグラフで可視化でき、挙動が予測しやすい点が特徴です。本記事では、これを使って「シンプルなタスク管理AI」を構築する手順を、Pythonのサンプルコードと共に具体的に紹介し、エージェント開発の基本を学びます。

G-gen の山崎です。当記事は、Google Cloud Next '26 in Las Vegas の2日目に行われたライトニングトークセッション「 8 Tips to Agentic Security Operations in 18 Minutes 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 AI を利用したセキュリティ運用における8つの Tips Tips 1: AI 推論の下に決定論的ルールを階層化する Tips 2: エージェントが必要とするデータを事前に計算する Tips 3: エージェントの権限を明示的に制限する Tips 4: ツールの出力は人間のためではなくエージェントのコンテキストウィンドウに合わせて設計する Tips 5: プロビナンスとリネージを通じてエージェントの決定に対する信頼を構築する Tips 6: 完璧な実行ではなくグレースフルデグラデーションを設計する Tips 7: 単体テストだけでなくシナリオハーネスを用いてシステムをテストする Tips 8: すべての要素、特にトークン使用量とアップストリームのレイテンシを観察する セッションの概要 Insight 社の John Giglio 氏と Hayden Holland 氏により、セキュリティ運用における AI エージェントの利用に関する実践的な8つの Tips が紹介されました。 セッションでは、AI を単なる確率論的な推論ツールとしてではなく、決定論的なシステムと組み合わせて安全かつ効率的に運用するための設計思想が語られています。 AI を利用したセキュリティ運用における8つの Tips Tips 1: AI 推論の下に決定論的ルールを階層化する エージェントの開発において、柔軟な AI の推論と、決定論的なルールベースの処理を組み合わせることが重要となります。AI の推論は確率論的であり、常に同じ結果を返すとは限りません。一方、決定論的なシステムは常に同じ結果を保証します。 セキュリティ領域においては、不確実性のある AI だけで環境に変更を加えることは大きなリスクを伴います。そのため、Insight 社では Site Reliability Engineering （以下、SRE）の手法に倣い、AI エージェントをデータのパターン認識や意思決定の補助として使用し、実際の実行部分は Python や Go 言語などで記述された決定論的なコードに委ねるアーキテクチャを採用しています。 SRE のマインドセットでは、運用業務を定期的に自動化して減らしていくことが求められますが、AI エージェントを使用することで、このプロセスをスピード感を持って対応することができます。 YAML や JSON スキーマ言語を多用してステップを定義し、期待される結果とそうでない結果を明確にしながらシステムを構築することで、AI エージェントは未知の脅威を探索する能力を提供し、決定論的なルールはシステムの安全な基盤を提供します。このように階層化することで、高い探索能力と耐久性のある実行の両立を実現できます。 Tips 2: エージェントが必要とするデータを事前に計算する Large Language Model （以下、LLM）を使用する推論やツール呼び出しには、多くのトークン消費とレイテンシが伴います。セキュリティ調査のたびに AI エージェントにあらゆる情報を探索させると、運用コストが膨大になり、回答を得るまでの時間も長くなります。 例えば、 MCP （Model Context Protocol）を使用して多数のツールをエージェントに接続し、すべてを自律的に推論させようとすると、処理が空回りし続ける可能性があります。この課題に対処するためには、エージェントにすべてを推論させるのではなく、エージェントが必要とするであろうデータを事前に計算し、準備しておくことが有効です。 エージェントには、明確に定義されたシステムプロンプトと、「この IP アドレスはウェブ環境で何をしているのか」といった特定のセキュリティのユースケースに特化した小さなスキル（skills）のみを使用させることが推奨されます。事前に与えられる情報が多いほど、エージェントの出力の精度は向上し、高価な LLM の呼び出し回数を最小限に抑えることができます。 参考 : What is the MCP and how does it work? 参考 : What is the Model Context Protocol (MCP)? Tips 3: エージェントの権限を明示的に制限する 現在、エージェントに自律的な意思決定をさせ、環境への変更権限を与えることには依然として高いハードルがあります。AI エージェントに対する完全な信頼が確立されていない段階では、エージェントの権限を明示的に制限するガードレールが不可欠です。コンテキストウィンドウ内に「何も編集しないで」という指示を含めたとしても、AI がそれを完全に遵守する保証はありません。 そのため、データを変更する可能性のあるツールの呼び出しについては、実行前に現在の権限レベルをチェックし、拒否ブロックを設ける必要があります。コンテキストウィンドウに指示を含めるだけでは、確実な保証は得られません。 2026年4月現在、多くの組織は「すべてを閲覧する」という読み取り専用の権限でエージェントを運用し、 Security Information and Event Management （SIEM）などのデータを通じて、エージェントの推論の精度を統計的に評価している段階とされています。 Tips 4: ツールの出力は人間のためではなくエージェントのコンテキストウィンドウに合わせて設計する エージェント間でデータを受け渡す際、ツールの出力結果はエージェントのコンテキストウィンドウに最適化されている必要があります。人間が見やすい形式で大量のデータをエージェントに渡すと、コンテキストウィンドウの上限に達し、重要な情報が無視されるなどの問題が発生します。システムは人間のためではなく、エージェントのために設計されなければなりません。 例えば、500件のファイアウォールルールのデータをそのまま返すよりも、関連性の高い上位10件の調査結果に絞り込み、「次に特定のルールについて詳細をクエリする」といったヒントを付与する方が効果的となります。エージェントは人間以上の情報を処理できる能力を持ちますが、コンテキストウィンドウの限界に配慮し、処理効率とのバランスを取る設計が求められます。適切なデータ量を提供することで、エージェントの能力を最大限に引き出すことができます。 Tips 5: プロビナンスとリネージを通じてエージェントの決定に対する信頼を構築する セキュリティチームがエージェントの自律的な意思決定を信頼するためには、ブラックボックスを排除し、推論の過程を検証できる仕組みが必要です。セッション内では、これを メタ可監査性 （Meta-auditability）と呼んで説明されています。 エージェントが導き出したすべての結論について、どのようなデータに基づき、どのような推論過程を経てそのツール呼び出しが行われたのかを遡って確認できるプロビナンスとリネージを設計に組み込む必要があります。セキュリティ担当者は本質的に懐疑的であり、証跡を直接確認できなければシステムを信頼しません。 運用の中でエージェントの行動パターンを継続的に監視・分析し、何十回も実行を繰り返す中で意思決定の傾向を把握します。この継続的な可視化を通じてのみ、少しずつシステムへの信頼を構築していくことができます。 Tips 6: 完璧な実行ではなくグレースフルデグラデーションを設計する システムの障害時に全体を停止させるのではなく、機能を縮小して稼働を継続する グレースフルデグラデーション の概念を、エージェントの設計にも取り入れることが推奨されます。 セキュリティ運用において、完璧な回答を待って時間がかかる、あるいは処理が失敗して何も情報が得られない状況は避けるべきであり、部分的でも正しい答えが得られるように出力結果に対してガードレールを設けることで、信頼性の高いシステムを目指すべきであると述べられました。 Tips 7: 単体テストだけでなくシナリオハーネスを用いてシステムをテストする エージェントをシステムとして本番環境に導入する前には、厳密なテストが不可欠です。しかし、単体テストや、結合テストによる検証だけでは不十分です。 AI エージェントが正しいセキュリティの意思決定を下すことを検証するためには、実際の運用に即したシナリオハーネスを使用する必要があります。サンドボックス環境を用意し、エージェントが予期せぬ挙動を示して制御不能に陥らないか、特定のシナリオにおいて適切なアクションを選択できるかを検証することが重要と語られました。 Tips 8: すべての要素、特にトークン使用量とアップストリームのレイテンシを観察する システムに対する信頼を維持するためには、エージェントの動作を継続的に観察し、可視化することが不可欠です。エージェントがどのような操作を行っているかを監視するだけでなく、トークン消費量やレイテンシの推移も把握する必要があります。 また、エージェントが機能しているように見えても、コンテキストが腐敗し、低品質な結果を出力し始めている可能性があります。コンテキストウィンドウの限界に近づいた際に見られる異常な応答やパフォーマンスの低下を検知するために、エージェントが行っているすべてを観察するという考え方を受け入れることが、安全な運用に繋がると述べられました。 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud Partner Top Engineer 2025 選出。 Google Cloud 全 13 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit