開発・検証用にintdashサーバーを動かしたいエンジニアのみなさん、 こんにちは、ソリューションアーキテクトの伊勢です。 intdashの2025年版からDockerでサーバー環境を構成できるようになりました。 製品マニュアルページで サーバーの構築 の1パターンとして AWS EC2上のDocker（簡易環境） の構築手順を公開しています。 1 今回はその理解を助けるため、各ステップの目的・準備・結果確認を噛み砕いてintdash環境を構築し、サーバーのログや設定を確認してみます。 2 はじめに 全体の流れ サーバー構成 AWS CDK 構築手順イメージ 手順前提 ツール準備 環境構築 準備 EC2インスタンス構築 アプリ起動 起動確認 SSLサーバー証明書設置 サーバードメイン名の準備 Let's Encryptで証明書設定 メールサーバー設定 管理者ユーザー設定 Google Maps APIキー設定 計測開始 intdash Motion起動 ログ確認 確認コマンド 計測時のログ確認 WebSocket接続 計測新規作成 アップストリーム開始 基準時刻受信 データ伝送 計測停止 負荷確認 AWSコンソール top コマンド 設定 設定確認 設定変更 バックエンド：ログイン試行回数変更 フロントエンド：ロゴ変更 おわりに はじめに 全体の流れ 全体像を捉えられるようにサーバーの構成から説明します。 サーバー構成の説明 EC2上にDockerでintdashサーバーを構築 ブラウザ・Motionから接続確認 データ送信とログ確認 負荷・データ・設定の確認 サーバー構成 通常、intdashのサーバーサイドは、2種類のインスタンスで構成されます。 3 APIインスタンス Webサーバー、API、認証、データ伝送、データやメディア管理 DBインスタンス ユーザー／エッジ／計測の保存、計測の時系列データの保存 通常のインスタンス・サービス構成 簡易環境では、1つのEC2インスタンスにAPI/DB双方のサービスが同居します。 4 EC2簡易環境 AWS CDK 簡易環境の構築にはAWS CDK（AWS Cloud Development Kit）を利用します。 AWS CDKとはインフラ構成をコードで記述したもので、このコードは AWS CloudFormation のテンプレートに変換されます。 AWS CloudFormation は、インフラ構成を定義したテンプレートで自動的に構築・更新・削除するサービスです。 CDKで生成したテンプレートをもとに CloudFormation がインフラを構築・更新・削除を自動化、状態を管理します。 構築手順イメージ 構築手順は大まかに ①〜③インフラ構築 ④〜⑥アプリ構築 にわかれます。 構築手順 作業用PC AWS CDKでテンプレートを生成してCloudFormationを起動します。 AWS CloudFormation テンプレートと元にAWSリソースを構築します。 EC2インスタンス Docker Composeで各サービスのコンテナを構成・起動します。 コンテナ構成定義から環境変数を読み込みます。 手順前提 事前に以下が必要です。 作業用PC AWS CLI、およびAWS CDKを実行します。 マニュアルのコマンドはLinux準拠です。 5 AWSアカウント EC2などのリソースが構築されるAWS環境です。 AWS IAMユーザー 作成するAWSリソースに権限が付与されている必要があります。 intdashライセンス アクティベーションキー intdashサーバーを有効化するため、設定します。 intdashライセンスを契約すると発行されます。 サーバードメイン名 サーバーにFQDNでアクセスするために必要です。 今回はAWS Route53で払い出す手順を紹介します。 ツール準備 作業用PCに必要なツールがインストールされているか確認します。 AWS CLI EC2へのSSH接続時、AWS CDK実行時の認証に使います。 Node.js Node.js 本体のバージョン管理ツールです。 npm パッケージを実行ツールです。AWS CDKスクリプトを実行します。 aws --version node -v nvm --version npm --version Node.jsのバージョンが古かったので最新版をインストールしました。 AWS CLI、Node.js / npmの確認 環境構築 準備 マニュアルの通り、以下を準備します。 6 AWS CLIの認証情報 キーペア作成、AWS CDKデプロイ時の認証のために設定します。 AWS CLI認証情報 EC2インスタンス構築 ここからインフラ構築を始めます。 まず、作業用PCで実行するデプロイ資材をダウンロードします。 CDK資材ダウンロード インタラクティブモードでAWS CDKのセットアップを開始します。 セットアップ開始 今回、intdash最新バージョンにあわせてRocky Linux 9イメージを使用します。 7 rockylinux.org Version: 9.7 Region: ap-northeast-1 Architecture: x86_64 Rocky Linux9.7イメージのAMI IDをコピー 確認したRocky Linux 9イメージのAMI IDを指定してデプロイします。 また、削除時のElastic IP保持を指定しています。 Elastic IPを確認 生成されたペアキーを安全な場所に置き、 EC2インスタンスにログインできるか確認します。 mv ./intdash-trial-key.pem ~/.ssh ssh -i ~/.ssh/intdash-trial-key.pem rocky@ < Elastic IP > sudo su - intdash ログイン確認 アプリ起動 セットアップが完了すると、すでにintdashサーバーが起動しています。 起動確認 ブラウザで https://intdash.<Elastic IP>.nip.io にアクセスします。 ログイン画面 ログインしてProject Consoleが表示されることを確認します。 Project Console画面 もしアクセスできない場合はログを確認します。 # ステータス確認 sudo systemctl status intdash-trial Docker Composeの全コンテナのログを確認する方法です。 auth-1 などコンテナ名が表示されます。 # リアルタイム表示 journalctl -u intdash-trial -f # 直近100行 journalctl -u intdash-trial -n 100 # 直近10分 journalctl -u intdash-trial --since " 10 minutes ago " 全コンテナログ ログインできない場合、Authentication Serviceのログを確認します。 特定コンテナのログを表示する方法です。 Docker Composeのサービス名 auth を指定します。 cd ~/deployment/ # 直近100行 docker compose -f docker-compose.yml logs auth | less # 直近10分 docker compose -f docker-compose.yml logs auth --since 10m | less 特定コンテナログ SSLサーバー証明書設置 このままではHTTPS通信ができません。 ブラウザではアクセスできますが、今回エッジとして利用する intdash Motion でアクセスできません。 続きの手順でHTTPS通信できるようにします。 SSLサーバー証明書設置前 今回は以下のように準備しました。 サーバードメイン名 今回はAWS Route 53で取得します。 サーバードメイン名の準備 本記事用に取得しています。 AWS Route53でドメイン名を購入します。最安で$15/月です。 ドメイン購入 登録に数分かかります。 完了するとVerifyメールが届きます。クリックします。 ドメイン登録のVerifyメール EC2インスタンスのIPアドレスを割り当てるサブドメインのレコードを作成します。 サブドメインレコード作成 全世界のDNSサーバーに登録が開始され、しばらくすると名前解決できます。 8 dig < サブドメイン名 > 名前解決成功 Let's Encryptで証明書設定 EC2インスタンス上でHTTPS通信のための証明書・秘密鍵を生成します。 Let’s Encrypt の証明書発行ツール Certbot をインストールする前に、Rocky Linuxのパッケージ管理コマンド DNF（Dandified Yum） で追加パッケージリポジトリ EPEL（Extra Packages for Enterprise Linux） をインストールします。 sudo dnf install -y epel-release sudo dnf makecache EPELインストール マニュアル通り、Certbot でSSLサーバー証明書と秘密鍵を発行します。 SSLサーバー証明書・秘密鍵発行 intdashサービス起動の前に、デプロイ資材の環境変数 FQDN を取得したサブドメイン名に変更します。 FQDN変更 これで intdash Motion でHTTPSアクセスできるようになります。 intdash MotionでHTTPSアクセス メールサーバー設定 マニュアル通りにメール設定を環境変数に追加します。 元の AUTH_SMTP_ADDRESS: " mail:1025 " AUTH_SMTP_HOSTNAME: " auth " はコメントアウトします。 9 メールサーバーと通知メール送信元を設定 AUTH_SMTP_PASSWORD に設定する <Gmail用のアプリパスワード> は Googleアカウント > 2段階認証プロセス > アプリ パスワード で発行します。 アプリパスワードの発行 管理者ユーザー設定 マニュアル通り、管理者ユーザーのメールアドレスを登録します。 メールアドレス追加 確認メール メールアドレス確認済み Google Maps APIキー設定 Google Maps APIキーを準備します。 Map JavaScript APIを有効化します。 自サイトだけで利用できるようウェブサイトでアプリケーションの制限を設定しておきます。 Google Maps APIキー準備 あとはマニュアル通り、Google APIキーを設定します。 Google Maps APIキー設定前 Google Maps APIキー設定後 計測開始 intdash Motion起動 intdash Motion の計測を起動します。 アップストリームを Edge Finder 、作成された計測を Meas Hub で確認します。 Edge Finderの確認 Meas Hubの確認 ログ確認 確認コマンド 全コンテナのログは journalctl で確認できます。 journalctl -u intdash-trial -f journalctl -u intdash-trial -n 100 journalctl -u intdash-trial --since " 10 minutes ago " 各テナントのログはDocker Composeの logs コマンドで確認できます。 cd deployment/ docker compose -f docker-compose.yml logs < container > | less docker compose -f docker-compose.yml logs < container > --since 1h | less なお、本構成では特にDocker Composeのロギング設定をしていません。 10 計測時のログ確認 計測起動時のBroker Serivceコンテナのログを確認してみます。 docker compose -f docker-compose.yml logs broker -f Broker Serviceコンテナログ WebSocket接続 Motionで計測を開始すると、一度WebSocketが切断されます。 "msg":"Received Disconnect" その後、改めてWebSocketの接続ログが出力されます。 "msg":"Received WebSocket:\tua:Motion/49 CFNetwork/3860.400.51 Darwin/25.3.0 referer: remote_ip:xxx.xxx.xxx.xxx:46928 proto:HTTP/1.1" "msg":"Received ConnectRequest request_id:0 protocol_version:2.0.0" "msg":"Authenticated by OAuthToken subject:c82b7aba-b9e1-46a8-a8b4-87c7384ce140" 計測新規作成 "msg":"Received","tenant_id":0,"project_id":"00000000-0000-0000-0000-000000000000","user_id":"c82b7aba-b9e1-46a8-a8b4-87c7384ce140" "path":"/api/v1/projects/00000000-0000-0000-0000-000000000000/measurements" アップストリーム開始 "msg":"Received UpstreamOpenRequest request_id: 2 session_id: 6fd90f07-0dca-47f0-8419-776b995bc876 qos: unreliable ack_interval: 100ms expiry_interval: 1m0s persist: true" "msg":"Succeeded in opening upstream. id=[4f5442cf-74e3-4f98-9695-0f566f5a3127] qos=[unreliable]","tenant_id":0,"message_track_id":"8565-2830-1198","transport_track_id":"4629-1820-3724" 基準時刻受信 "msg":"Received UpstreamMetadata request_id: 4 metadata: *message.BaseTime" 計測開始からここまでが一気に出力されます。 データ伝送 継続中は以下が続きます。 "msg":"MessageCount rx: 0 [msg/sec] tx: 3 [msg/sec]","tenant_id":0,"message_track_id":"6601-6588-7707","transport_track_id":"1239-5713-3538" .. "msg":"MessageCount rx: 1 [msg/sec] tx: 6 [msg/sec]","tenant_id":0,"message_track_id":"6601-6588-7707","transport_track_id":"1239-5713-3538" 計測停止 Motionで計測を停止すると以下が出力されます。 "msg":"Received UpstreamCloseRequest request_id: 8 stream_id: 4f5442cf-74e3-4f98-9695-0f566f5a3127" stream_id は Succeeded in opening upstream. の id と一致しています。 負荷確認 運用でよく確認するサーバー負荷を見てみます。 Motion から以下のデータを5分間ほど送信します。 わかりやすく負荷を上げるために映像データを最大量で送信してみました。 11 映像: H.264 FullHD 30 FPS 8.2 Mbps 音声: PCM IMU GPS 瞬間的に8〜12 Mbps超 AWSコンソール AWSコンソールで推移を確認します。 AWSコンソールの確認 CPUが40%、データ受信が40 MB（≒ 5.5 Mbps）を超えています。 top コマンド top コマンドでメモリの推移を確認します。 top コマンド確認 メモリ使用は 6.5 GBを超えています。 なお、データ格納領域 /data が 98 GB ほど使われています。 df コマンド確認 設定 設定確認 秘匿情報や環境固有情報は、デプロイ資材の .env ファイルからDocker Composer設定ファイルに伝播するようになっています。 例えば、先ほど設定した FQDN は NGINX_SERVER_NAME などに伝播します。 docker-compose.yml 設定変更 では、一部の設定を変更してみましょう。 バックエンド：ログイン試行回数変更 わかりやすい例として Authentication Service の設定を変更します。 Authentication Service user-password attempt-limit : パスワード試行回数のリミット デフォルト値: 5 この回数間違えるとユーザーはロックされます。 正しいパスワードでもログインできなくなります。 ログインするにはロック解除かパスワード再発行が必要です。 Authentication Serviceの項目を持つ docker-compose.api.yml を編集します。 パスワード試行回数のリミットを1回に変更します。 サービス名、セクション名、設定項目をつなげて項目名を AUTH + _ + USER_PASSWORD + _ + ATTEMPT_LIMIT にします。 AUTH_USER_PASSWORD_ATTEMPT_LIMIT : 1 サービス auth を再起動します。 docker compose up -d auth パスワード試行回数の変更・再起動 Admin Consoleでユーザー test を作り、ログインを1度失敗します。 ログイン失敗 intdash ユーザーで test ユーザーを確認すると "ロック中" になっています。 ログイン試行1回失敗でロック中 フロントエンド：ロゴ変更 例外として、フロントエンドはWebデプロイ資材を直接書き換えます。 今回はData Visualizerのロゴを変更してみます。 標準は画面左上に出てくる VISUAL M2M の画像です。 標準ロゴ 以下の設定項目を変更します。 VM2M Data Visualizer（フロントエンド） vm2m-2nd-configの設定 header logoImgURL : Data Visualzierのヘッダロゴ AWS S3に配置・公開した 幅200px、高さ56px のPNGファイルを指定します。 PNGファイルS3配置 cd deployment/ vi docker/ui-conf/vm2m-data-viz-backend/config/vm2m-2nd-config/vm2m-2nd-config.production.json " header ": { " logoImgURL ": " https://s3.ap-northeast-1.amazonaws.com/<S3_BUCKET_NAME>/docker.png " } , vm2m-2nd-configの編集 Data Visualizerサービスを再起動してData Visualizerを表示します。 docker compose restart vm2m-data-viz-backend カスタムロゴ おわりに Dockerで開発用のintdash環境を構築してみました。 普段は意識しないサービスやDB構造を確認することで理解が深まり、 設定やログ、パフォーマンスを見ることで運用イメージがつきました。 設定項目は他にも多くあるので、また別の機会にご紹介できればと思います。 簡易環境の構築方法としては、これまでAWS マーケットプレイスにAMIを提供していました。コンテナイメージとDocker Composeでの仮想化により、AWS以外での構築方法と統合され、バージョン最新化も容易になりました。 ↩ 構築および運用手順はintdashの公式マニュアルをご参照ください。閲覧にはユーザー登録が必要です。 ↩ 冗長構成では各サービスごとにインスタンスが細分化、またスケールアウトします。 ↩ 簡易環境は開発用途の構成であり、本格的な運用には向きません。本番環境向けの構成は Kubernetes または RPM で構築します。 ↩ WindowsではWSLのUbuntu環境などで実行できます。 ↩ 本記事では、基本的に公式マニュアルに沿って進め、各ステップで「どういう目的で何が行われているか」「構築結果をどう確認するか」にフォーカスして解説します。 ↩ 利用するAMI IDはリージョンなどにより異なるため、Rocky Linux公式サイトで最新のものを確認してください。 ↩ ICMPポートは開けていないため、pingは通りません。 ↩ デフォルトではコンテナ内のSMTP（mailコンテナ）を使用していますが、外部SMTP（Gmail等）を利用するように変更します。 ↩ ログはDockerコンテナが再作成されると消えてしまいます。必要に応じて Docker Compose の設定で syslog 等で外部保存します。 ↩ なお、Motion側のWi-Fi帯域を超えており、データ量の86.4 %しか送信できていません。 ↩

この記事は、さくらインターネットが実施した高火力 DOKハンズオンの参加者に提供していた資料を、一般公開するために記事化したものです。 はじめに OpenVoiceとは？ OpenVoiceは、ボイスクローンができるAI […]

Spec-Driven Presentation Maker は、「何を伝えるか」を先に設計し、スライドの構築を AI に委ねるオープンソースのサンプル実装です。本記事では、仕様駆動アプローチの考え方と、AWS 環境への導入方法をご紹介します。 プレゼン資料、「伝えたいこと」から作れていますか 多くの組織で、プレゼンテーション資料の作成は日常的な業務です。提案書、社内報告、技術共有、経営会議の資料 — いずれも、限られた時間の中で「伝わる資料」を作る必要があります。 しかし実際には、白紙のスライドを開いてから完成するまでの時間の多くが、レイアウトの調整、フォントや色の選定、図表の配置といった「見た目の作業」に費やされています。本来最も重要な「何を、どの順序で、なぜ伝えるのか」というメッセージの設計は、作業の合間に考えることになりがちです。 その結果、見た目は整っているものの、核心のメッセージが伝わりにくい資料ができあがることがあります。あるいは、構成が定まらないまま作り始めたために、途中で大幅な手戻りが発生することもあります。 この課題は、資料作成のプロセスそのものに起因しています。 AI に「作って」と言うだけでは解決しない理由 近年、生成 AI を活用したスライド作成ツールが登場しています。「プレゼン資料を作って」と指示すれば、AI がスライドを生成してくれる — 一見すると、前述の課題を解決できるように思えます。 しかし、AI に漠然とした指示を出した場合、生成される資料は「それらしい見た目」にはなるものの、伝えたいメッセージの論理構造や、聞き手に合わせた情報の取捨選択が不十分になりがちです。これは、AI が「何を伝えるべきか」の判断を十分に行えないまま、「どう見せるか」の作業に進んでしまうためです。 つまり、従来の手作業でも AI 任せでも、「設計なき資料作成」という根本的な課題は変わりません。必要なのは、メッセージの設計と、スライドの構築を明確に分離するアプローチです。 仕様駆動プレゼンテーションという考え方 Spec-Driven Presentation Maker は、ソフトウェア開発で広く実践されている「先に設計してから作る」という考え方を、プレゼンテーション資料の作成に応用しています。 ソフトウェア開発では、コードを書き始める前に要件定義や設計書を作成します。同様に、仕様駆動プレゼンテーションでは、スライドを作り始める前に「何を伝えるか」の設計書（仕様）を先に作成します。 ただし、設計書を一人で書き上げる必要はありません。AI との対話を通じて、聞き手の分析、論理構造の検討、メッセージの精緻化を一緒に進めていきます。AI がたたき台を提示し、利用者がフィードバックを返すことで、設計書の質を高めていくプロセスです。 具体的には、以下の 3 つのフェーズで資料を設計します。 仕様駆動プレゼンテーションの 3 フェーズ。「何を伝えるか」を段階的に設計してから、AI がスライドを生成します 1. ブリーフィング — 聞き手は誰か、何を伝えたいか、聞き手にどうなってほしいかを定義します 2. アウトライン — 1 スライド 1 メッセージの原則で、各スライドが答えるべき疑問と、その答えを定義します 3. アートディレクション — 色使い、フォント、ビジュアルの方向性を定義します この設計書が完成した後に、AI がテンプレートに準拠してスライドを生成します。設計と構築が分離されているため、メッセージの質を保ちながら、構築のスピードを大幅に向上できます。 従来の資料作成 仕様駆動プレゼンテーション 起点 白紙のスライド ソース資料と要件 設計 作りながら考える 先に論理構造を設計書として定義 構築 手作業でレイアウト AI がテンプレートに準拠して生成 品質 属人的 設計書に基づくレビュー可能なプロセス 資料ができるまでの流れ Spec-Driven Presentation Maker では、AI エージェントが対話を通じて設計書を作成し、スライドを構築します。利用者が行うのは、チャットでの対話と、設計内容の確認です。 Web UI の画面。デッキ一覧から資料を選択し、右側のチャットで AI と対話しながら設計・構築を進めます 1. 対話による設計 — AI が聞き手や目的についてヒアリングし、ブリーフィングを作成します。続いて、1 スライド 1 メッセージの原則でアウトラインを設計し、ビジュアルの方向性を決定します アウトラインの設計画面。各スライドのメッセージ、根拠（Evidence）、ビジュアル指示が構造化されて表示されます 2. スライドの自動構築 — 設計書に基づいて、AI がテンプレートのレイアウトやカラーに準拠しながらスライドを構築します 3. プレビューとレビュー — 生成されたスライドの PNG プレビューを確認し、AI との対話で修正を指示できます 生成されたスライドのプレビュー。グリッド表示で全体の流れを確認でき、チャットから画像配置などの修正指示も可能です 設計書（ブリーフィング、アウトライン、アートディレクション）はすべて保存されるため、後から設計意図を振り返ることができます。また、設計書をレビューすることで、スライドを作る前の段階で内容の妥当性を確認できます。 自社のテンプレートとブランドをそのまま活用 Spec-Driven Presentation Maker の特徴の一つは、既存の PowerPoint テンプレートをそのまま利用できることです。 Spec-Driven Presentation Maker で生成されたスライドの例。データビジュアライゼーション、引用、アジェンダなど多様なレイアウトが自動で選択されます お使いの企業テンプレート（.pptx ファイル）をアップロードするだけで、テンプレートに定義されたレイアウト、カラーテーマ、フォント設定が反映されます。AI は、テンプレートのデザインシステムに準拠してスライドを生成するため、企業のブランドガイドラインに沿った資料が作成されます。 同じ内容でも、テンプレートを変えるだけでデザインが変わります。左がダークテンプレート、右がライトテンプレート また、 AWS Architecture Icons や Material Symbols などのアイコンセットにも対応しており、アーキテクチャ図やフロー図を含むスライドも作成できます。独自のアイコンセットを追加することも可能です。 画像を渡すだけでスライドに Spec-Driven Presentation Maker は、画像の内容を理解してスライドに変換する機能も備えています。写真やイラストを渡すと、AI が画像の内容を分析し、それに合ったレイアウト・テキスト・スタイルを自動で選択してスライドを生成します。 画像を渡すだけで、内容を理解した上でスライドを自動生成。テンプレートのスタイルに合わせてレイアウトやフォントも自動選択されます 2 つの使い方 — ブラウザから、または普段の AI ツールから Spec-Driven Presentation Maker は、利用者のスキルや好みに応じて 2 つの方法で利用できます。 ブラウザから使う Web UI を使えば、ブラウザ上のチャットインターフェースから資料を作成できます。特別なツールのインストールは不要です。チャットで AI と対話しながら、同じ画面でスライドのプレビューを確認し、PPTX ファイルをダウンロードできます。 Web UI のダッシュボード。作成した資料の一覧がカード形式で表示されます。お気に入り、共有、組織内公開などのフィルタリングも可能です チームメンバーとの共有機能も備えており、作成した資料を他のメンバーに公開したり、共同編集者として招待したりできます。 普段の AI ツールから使う 開発者やパワーユーザーは、普段お使いの AI コーディングエージェント（ Kiro 、Claude Desktop、VS Code など）から直接資料を作成することもできます。MCP（Model Context Protocol）を通じて AI コーディングエージェントにサーバーを追加するだけで、チャットの中で資料作成の指示を出せます。 社内の AI チャット基盤に組み込む Spec-Driven Presentation Maker はリモート MCP サーバーとして独立して動作するため、MCP に対応した社内の AI チャット基盤にも組み込むことができます。たとえば、 Generative AI Use Cases（GenU） の AgentBuilder 機能を利用すれば、GenU のチャット画面からプレゼンテーション資料を作成できるようになります。既存の AI 基盤に「資料作成」という新しいケイパビリティを追加する形で導入できる点も、このアセットの特徴です。 この柔軟性により、組織内のさまざまな役割の方が、それぞれに合った方法で利用を開始できます。 アーキテクチャ — 必要なレイヤーだけ使う Spec-Driven Presentation Maker は 4 層アーキテクチャで構成されています。各レイヤーは前のレイヤーの薄いラッパーであり、必要なレイヤーだけを選んで利用できます。 ユースケース レイヤー AWS Kiro CLI で個人利用 Layer 1: skill/ 不要 ローカル MCP（Claude Desktop、VS Code、Kiro） Layer 2: skill/ + mcp-local/ 不要 チームデプロイ Layer 3: + mcp-server/ + infra/ 必要 フルスタック（Web UI + チャット） Layer 4: + agent/ + api/ + web-ui/ 必要 Layer 1・2 は AWS アカウント不要で、ローカル環境だけで動作します。個人利用から始めて、チームでの利用が決まった段階で Layer 3・4 に拡張するという段階的な導入が可能です。 始め方 — CloudShell から数ステップでデプロイ Spec-Driven Presentation Maker は、AWS CloudShell から数ステップでデプロイできます。ローカル環境に AWS CDK や Docker をインストールする必要はありません。 git clone https://github.com/aws-samples/sample-spec-driven-presentation-maker.git cd sample-spec-driven-presentation-maker ./scripts/deploy.sh --region us-east-1 デプロイが完了すると、Amazon CloudFront の URL が発行されます。ブラウザでアクセスし、Amazon Cognito のユーザーを作成すれば、すぐにチームで資料作成を始められます。 すべてのリソースはご自身の AWS アカウント内にデプロイされます。資料のデータ（スライド、テンプレート、プレビュー画像）は Amazon S3 と Amazon DynamoDB に保存され、AWS 外部のサードパーティサービスにデータが送信されることはありません。認証には Amazon Cognito を使用し、リソースレベルのアクセス制御により、資料ごとに閲覧・編集権限を管理できます。 個人利用やローカル環境での利用方法については、 リポジトリのドキュメント をご参照ください。 まとめ Spec-Driven Presentation Maker は、「何を伝えるか」の設計と「どう見せるか」の構築を分離することで、プレゼンテーション資料の質とスピードを両立するオープンソースのサンプル実装です。 仕様駆動アプローチにより、メッセージの論理構造を先に設計し、AI がテンプレートに準拠してスライドを生成します 既存の企業テンプレートをそのまま活用でき、ブランドガイドラインに沿った資料を作成できます ブラウザ、AI コーディングエージェント、社内 AI 基盤など、多様なインターフェースから利用できます 4 層アーキテクチャにより、個人利用からチームデプロイまで段階的に導入できます ご自身の AWS アカウント内にデプロイされるため、データの管理はお客様自身の手の中にあります 次のプレゼン資料を作成する機会に、ぜひお試しください。 リンク集 GitHub リポジトリ アーキテクチャドキュメント CloudShell デプロイガイド カスタムテンプレートとアセット エージェント接続ガイド 著者/開発者紹介 片岡 翔太郎 (Shotaro Kataoka) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 本アセットの設計・開発を担当。 AI/ML関連で博士号取得後 2025 年に入社した SA。最近初めての娘が生まれ、家では常に抱っこをしている。業務効率化ツールの開発が趣味で、Kiro CLI を片手にいつも何かを作っている。 吉川 直仁 (Naohito Yoshikawa) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 本アセットの設計・開発を担当。 大学で AI/ML の研究を行い、昨年（2025/04）SA として新卒入社。Kiro CLI で仕事を効率的にしようとするも、何かを作り続けているので結局忙しい。 岡本 晋太朗 (Shintaro Okamoto) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 本アセットの設計・開発を担当。 育休から復帰後、生成 AI の進化をキャッチアップ中。今年の目標は家事を技術で楽にすること。Kiro はかわいいので IDE 推しだったが、最近は CLI も愛用。