こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2025 年 11 月・ 12 月合併号 はお読みいただけましたでしょうか。2026 年のアップデートをお届けする最初のブログ更新となります。本年も Amazon Connect の最新情報や有益な情報をお届けできるよう努めてまいります。皆さんのお役に立つ内容があれば幸いです！ 今月は 以下の内容でアップデート情報をお届けします。 Amazon Connect Starter Kit のご紹介 2026 年 1 月のアップデート一覧 AWS Contact Center Blog のご紹介 1. Amazon Connect Starter Kit のご紹介 Amazon Connect で AI エージェントを活用したコンタクトセンターをすぐに構築・体験できるスターターキット( sample-amazon-connect-starter-kit-japan )をご紹介します。本パッケージの最大の特徴は、デプロイするだけで AI エージェントを活用したコンタクトセンター環境が即座に利用可能になる点です。Amazon Connect AI エージェントを中心に、音声・チャットの複数チャネルに対応した環境が自動的に構築されます。複雑な設定作業は不要で、付属のデプロイメントガイドに従うだけで環境が完成します。 最新の AI エージェント機能を体感 Amazon Connect の AI エージェントは、従来の Amazon Q in Connect から進化した、より高度な自律型 AI です。顧客は「Connect アシスタント」と呼ばれる会話型インターフェイスを通じて AI エージェントとやり取りし、複雑でオープンエンドな問い合わせにも対応できます。ナレッジベースを参照した自動応答、複数の意図を含む問い合わせへの対応、コンテキストを維持した会話など、最新の Agentic AI 機能を実際に体験できます。 Amazon Connect では 最新のAgentic AI エージェントだけでなく、従来のAmazon Lex でのインテントベースの決定論的 AI も引き続き利用可能です。AI エージェントが複雑でオープンエンドなやり取りを処理する一方、決定論的 AI は事前定義されたインテントや特定の会話フローを処理します。この組み合わせにより、従来の決定論的 AI と自律的な Agentic AI の両方の長所を活用したセルフサービス体験を提供できます。 日本語・日本リージョン対応 us-east-1(バージニア北部)と ap-northeast-1(東京)の両リージョンでのデプロイに対応しています。また、日本語での利用を前提とした設定やドキュメントが含まれており、日本のコンタクトセンター環境ですぐに活用できます。 2. 2026 年 1 月のアップデート一覧 Amazon Connectが待ち時間予測の精度を向上 – 2026/01/31 Amazon Connect では、キューおよびキューに入っているコンタクトに対する待ち時間予測メトリクスが改善されました。これにより、コンタクトセンターは顧客に正確な待ち時間を伝えられるようになり、待ち時間が長い場合にはコールバックなどの便利なオプションを提供したり、複数のキュー間で業務負荷を効果的に分散したりできるようになります。改善された待ち時間予測メトリクスを活用することで、コンタクトセンターはキュー間でより戦略的なルーティング判断を行えるようになり、リソース計画のための可視性も向上します。たとえば、ピーク時に請求に関する問い合わせで15分の待ち時間が発生している場合、2分で対応可能なクロストレーニングされたチームにシームレスに転送することで、顧客は問題を繰り返し説明することなく、より早くサポートを受けられます。このメトリクスは、ルーティング条件やエージェントの習熟度設定とシームレスに連携します。 関連リンク 管理者ガイド Amazon Connect Cases に対するきめ細かなアクセス制御をサポート – 2026/01/28 Amazon Connect では、ケースに対してタグベースのアクセス制御を適用できるようになり、管理者はケースデータの閲覧と管理をより詳細に制御できるようになりました。この機能により、ケーステンプレートにタグを関連付け、セキュリティプロファイルを設定することで、特定のタグが付いたケースにアクセスできるユーザーを制御できます。たとえば、不正行為に関連するケースにタグを付け、不正対策のセキュリティプロファイルが割り当てられたユーザーのみがそれらのケースを閲覧または編集できるようにアクセスを制限することが可能です。これにより、社内統制の強化やデータアクセスポリシーの徹底が実現できます。 関連リンク 管理者ガイド Amazon Connect のステップバイステップガイドに条件分岐ロジックとリアルタイム更新機能が追加 – 2026/01/23 Amazon Connect のステップバイステップガイドが強化され、マネージャーはより動的で柔軟性の高いガイド体験を構築できるようになりました。ユーザーの操作に応じて変化する条件付きユーザーインターフェースを作成できるため、ワークフローの効率が向上します。たとえば、マネージャーはドロップダウンメニューを設定し、前の項目への入力内容に基づいて、フィールドの表示・非表示を切り替えたり、デフォルト値を変更したり、必須項目を調整したりすることができます。これにより、さまざまなシナリオに合わせたカスタマイズされた体験を提供できます。さらに、ステップバイステップガイドは、フローモジュールなどの Connect リソースから指定した間隔でデータを自動的に更新できるようになり、エージェントは常に最新の情報を使って業務を行えるようになりました。 関連リンク 管理者ガイド Amazon Connect が評価目的でのエージェントのコンタクトのランダムサンプルの自動選択を開始 – 2026/01/21 Amazon Connect において、エージェントの評価を目的としたコンタクトのランダムサンプリング機能が追加されました。この機能により、マネージャーはエージェントに対して適正なコーチングとフィードバックを提供できるようになります。マネージャーは、労働協約や社内ガイドラインに従って、エージェントごとに確認が必要なコンタクト数を指定できます。指定した数のコンタクトは、設定した期間からランダムに抽出されます。たとえば、先週の期間からエージェント 1 人あたり 3 件のコンタクトを自動的に選択することが可能です。さらに、新しいフィルター機能を使用することで、評価に適したコンタクトを確実に選択できます。音声録音、画面録画、トランスクリプトが含まれるコンタクトに絞り込んだり、過去に評価済みのコンタクトを除外したりすることができます。これにより、マネージャーは効率的かつ公平にエージェントのパフォーマンスを評価し、質の高いフィードバックを提供できるようになりました。 関連リンク 管理者ガイド Amazon Connect がデータレイクでのエージェントのスケジューリングメトリクスの提供を開始 – 2026/01/15 Amazon Connect がデータレイク内でエージェントのスケジューリングメトリクスを提供するようになり、このデータからレポートやインサイトを簡単に生成できるようになりました。たとえば、来月のスケジュール公開後に、Connect の分析データレイク内で、予測される人数、スケジュールされた人数、予想されるサービスレベルなど、15 分または 30 分間隔のメトリクスにアクセスできます。ビジネスユニット全体(予測グループ)の集計メトリクスを利用したり、特定の需要セグメント(需要グループ)別に分類したりすることが可能です。その後、Amazon QuickSight または任意の BI ツールでこのデータを可視化して、人員過剰や人員不足になっている期間を特定するなど、さらに詳細な分析を行えます。これにより、エージェントのスケジュールを手動で確認する必要がなくなり、スケジューラとスーパーバイザーの生産性が向上します。 関連リンク 管理者ガイド Amazon Connect で営業時間の定期的なオーバーライドの簡単な管理が可能に – 2026/01/14 Amazon Connect で、日、月、または年単位で一目で確認できるカレンダー表示を使用して、休日、メンテナンス期間、プロモーション期間などの定期的なイベントに応じたコンタクトセンターの営業時間を簡単に管理できるようになりました。毎週、毎月、または隔週の金曜日に自動的に有効になる定期的なオーバーライドをセットアップすることで、カスタマーエクスペリエンスをパーソナライズできます。すべての設定は自動的に適用されるため、手動で再確認する必要はありません。たとえば、エージェントの稼働状況を確認することなく、毎年 1 月 1 日に自動的に顧客へ「新年あけましておめでとうございます」という挨拶を送り、特別なホリデーメッセージに誘導できます。1 月 2 日には自動的にコンタクトセンターが通常業務に戻ります。 関連リンク 管理者ガイド Amazon Connect Cases が AWS CloudFormation のサポートを開始 – 2026/01/13 Amazon Connect Cases で AWS CloudFormation のサポートが開始され、Infrastructure as Code として Cases のリソースをモデル化、プロビジョニング、管理できるようになりました。今回のリリースにより、管理者は CloudFormation テンプレートを作成して、Amazon Connect インスタンス全体にわたって Cases の設定(テンプレート、フィールド、レイアウトなど)をプログラムによってデプロイおよび更新できます。これにより、手動でのセットアップ時間を短縮し、設定エラーを最小限に抑えることができます。 関連リンク 管理者ガイド Amazon Connect でエージェント画面録画の状況を追跡する機能の提供を開始 – 2026/01/13 Amazon Connect では、Amazon EventBridge を使用して CloudWatch でエージェントの画面録画の状況をほぼリアルタイムで表示できるようになりました。スーパーバイザーは画面録画を使用することで、顧客との通話を聞いたり、チャットの文字起こしを確認したりするだけでなく、問い合わせを処理する際のエージェントのアクション(音声通話、チャット、タスクなど)を監視できます。これにより、エージェントにコーチングが必要な領域(たとえば、ビジネスプロセスの違反など)を特定できます。Amazon EventBridge を使用すると、成功・失敗のステータス、失敗コードとその説明、インストールされているクライアントのバージョン、エージェントのウェブブラウザのバージョン、エージェントのオペレーティングシステム、画面録画の開始と終了の時刻など、各エージェントの画面録画の状況を CloudWatch から確認できます。Amazon EventBridge イベントバスの「Screen Recording Status Changed」イベントタイプにサブスクライブすることで、Amazon Connect 画面録画の状況追跡機能の使用を開始できます。 関連リンク 管理者ガイド ネストされた JSON オブジェクトとループ配列を格納する機能が Amazon Connect で提供される – 2026/01/03 Amazon Connect では、複雑なデータ構造をフローに保存して処理できるようになったため、社内のビジネスシステムから返される豊富な情報を使用する動的な自動化エクスペリエンスを簡単に構築できます。ネストされた JSON オブジェクトやリストを含む完全なデータレコードを保存し、JSON 形式で返された注文のリストから、特定の注文など、その中の特定の要素を参照できます。さらに、カスタマーサービスフロー内の項目のリストを自動的にループ処理して、ループ内の現在の位置を追跡しながら、各エントリを順番に処理できます。これにより、アイテムレベルの詳細に簡単にアクセスし、関連情報をエンドカスタマーに提示できます。たとえば、旅行代理店は、1 回のリクエストで顧客の旅程をすべて取得し、電話をかけてきた顧客に各予約を案内して、予約を確認または更新することができます。銀行も同様に、システムから安全に取得したデータを使用して、最近の取引を1つずつ顧客に説明できます。これらの機能により、ビジネスシステムを繰り返し呼び出す必要がなくなり、ワークフローの設計が簡単になり、ビジネス要件の変化に適応する高度な自動エクスペリエンスの提供が容易になります。 関連リンク 管理者ガイド 3. AWS Contact Center Blog のご紹介 テスト時間を最大 90% 削減 – Amazon Connect のテストとシミュレーション機能 (日本語翻訳) コンタクトセンター管理者は、本番環境を中断することなくコンタクトフローを効率的にテストする課題に直面してきました。従来は手動でシステムに電話をかけたり、カスタム検証ツールを構築したり、サードパーティソリューションに投資する必要があり、時間とコストがかかっていました。Amazon Connect は、このような課題を解決するネイティブコールシミュレーション機能の一般提供を開始しました。この機能により、外部ツールや手動での電話テストなしでコンタクトセンターワークフローを自動的にテストでき、検証時間を最大 90 %削減できます。テストフレームワークは、イベント駆動型モデルと直感的なビジュアルインターフェースを採用しており、技術者以外のチームメンバーでも簡単にテストを作成できます。「X が発生したら Y を実行する」という自然な観点でテストを記述し、Observe (観察)、Check (検証)、Action (アクション)の 3 つのブロックを組み合わせてテストシナリオを構築します。専用のテストダッシュボードでは、テスト実行履歴や成功率、失敗の詳細な洞察が得られ、継続的な改善を推進できます。本ブログ記事では、Amazon Connect の新しいネイティブテストとシミュレーション機能を活用して、コンタクトセンターの検証を自動化する方法について紹介しています。 Amazon Connect の裏側: イノベーターとしての進化 (日本語翻訳) Amazon Connect は、2007 年に Amazon の内部カスタマーサービスチームが3つのコンタクトセンターベンダーを置き換えるために構築した統合ソリューションから始まりました。従来の方法では 300 万ドルの前払い投資が必要でしたが、内部ソリューションはより安価で、Amazon のミッションを体現するものでした。Audible や Zappos など新たに買収された企業も熱心に採用し、年間推定 6,000 万ドルの節約を実現しました。2017 年のパブリックローンチ後、Capital One、Hilton、GE などの大企業が、従来 1 年間かかっていた構築プロセスを週末のプロジェクトに変えるクラウドネイティブなアーキテクチャに魅力を感じ、急速に採用が進みました。2019 年に AI を活用した会話分析や感情分析をローンチし、2023 年には Forrester と Gartner の主要レポートでリーダーシップポジションを獲得しました。生成 AI の出現により、自動エージェントラップアップや通話要約などの機能を提供し、2024 年 12 月には 60 億分、2025 年には 120 億分の顧客とのやり取りを AI で最適化しました。先週の Q3 2025 年決算報告では、年間換算売上高 10 億ドルのペースを達成したことが発表されました。本ブログ記事では、Amazon の内部ソリューションから AI のパイオニアへと進化した Amazon Connect のストーリーと、今後のエージェンティック AI への展望について紹介しています。 How NatWest Simplified Contact Center Analytics with Amazon Connect analytics data lake (英語記事) 英国の大手金融機関 NatWest Group は、2019 年に Amazon Connect を導入しましたが、当初はカスタム ETL パイプラインを使用したデータ処理に大規模なメンテナンスと定期的な更新が必要で、運用の複雑さとコストの増加に直面していました。2024 年、NatWest は Amazon Connect 分析データレイクの Zero ETL アーキテクチャを採用し、データアクセスと分析を大幅に簡素化しました。この移行により、従来 2 か月かかっていた CTR パイプラインの構築がわずか1週間で完了するようになり、通話完了から 1 時間以内にデータが利用可能になることで、タイムリーな意思決定が可能になりました。Zero ETL アプローチにより、センチメント分析や通話結果などの事前処理されたメトリクスに即座にアクセスでき、IVR パフォーマンスダッシュボードや会話品質分析ダッシュボードを通じて顧客インタラクションに関する多次元的な洞察を得られるようになりました。本ブログ記事では、NatWest が Amazon Connect 分析データレイクを活用してコンタクトセンター分析を簡素化し、データドリブンな顧客サービスを実現した事例について紹介しています。 今月のお知らせは以上です。皆さまのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 梅田 裕義

Figmaの手作業から脱却したい ども！最近は図解の自動化にハマっている龍ちゃんです。 技術ブログの図解、みんなどうしてますか？ 僕は以前、Figmaで人力で図を作ってたんですよね。アーキテクチャ図とかフロー図とか、1つ作るのに結構な時間がかかる。ブログの本数が増えるほど、だんだん図を作るのが億劫になってきて。 で、 SVG図解自動生成 、 HTML図解自動生成 と試行錯誤を重ねてきました。過去記事を読んでなくても今回の記事だけで完結するので、安心してください。 やっていることはシンプルで、Claude Code の SKILL で HTML 図解を自動生成して、CLI ツールで PNG に変換する。ここまではツールの話なんですが、今回伝えたいのはその先で、 気に入ったデザインを reference に突っ込んでスキルを「育てる」ことができる んですよね。これがめっちゃ重宝してます。 ぶっちゃけ僕が作るよりも、たまにいいデザインを作ってくるから最高なんですよ。んで、そのいいやつを保存しておくと、次からもっと良くなる。 今回の内容です。 自然言語で図解を爆速で作る ブラウザ立ち上げ不要でスクショをとる 自分専用のデザイナーに育てる方法 実際にやってみた結果と、正直な限界 仕組みの全体像 なぜ HTML + Tailwind なのか ここに至るまでに色々試しました。ざっくり経緯を話すと: Mermaid : 手軽なんですけど、図の種類が制限されるんですよね。使用場所を選ぶ感じです（ Mermaid図作成の記事 も書いてます） SVG : トークンだけバカ食いして、あんまりいい出力じゃなかった。座標計算が苦手で、文字はみ出しとか要素の重なりが頻発してました HTML+Tailwind : Claude は CSS（Flexbox/Grid）が得意。HTMLだと自力で修正もできる 方式 良い点 課題 Mermaid 手軽 図の種類が制限される SVG 自動生成可能 トークン食い・ズレやすい HTML+Tailwind 自動生成＋修正しやすい PNG変換が必要 HTMLは最初からうまくいったわけじゃなくて、参考になりそうなHTMLとかデザインプラクティスを調べて改善していった結果です。前回の記事では3つの実例が全て修正不要で完成するレベルまで持っていけました。あと、HTMLだと気に入ったデザインをパーツごとに蓄積させておくことで、自分だけのデザインブックが作れるんですよね。これが後で効いてきます。 Claude Code の SKILL って何？ Claude Code を使ってない人もいると思うので、ここだけ少し補足します。 一言で言うと「AIへの作業手順書」 です。 .claude/skills/ ディレクトリに SKILL.md というファイルを置いておくと、Claude が指示を受けた時に自動でそのファイルを読んで実行してくれます。 例えば「アーキテクチャ図を作って」と言うと、Claude は図解生成用のスキルファイルを見つけて、「どんなHTMLで」「どんなルールで」「どんなサイズで」作るかを理解した上で図を生成してくれる。毎回同じ説明をしなくていいんですよね。 ここで大事なのが Progressive Disclosure（段階的開示） という設計です。 Level 1 : スキルの名前と説明（常時ロード。軽い） Level 2 : SKILL.md 本体（スキルが起動した時にロード） Level 3 : references/ ディレクトリ（必要な時にだけロード） この Level 3 が後で「育てる」話に繋がるので、覚えておいてください。 実際に作った図解スキルの中身 じゃあ実際に僕が作った diagram-generator-html というスキルを見てみましょう。 HTML5 + Tailwind CSS + Material Icons で 1280x720px 固定サイズの図解を生成します。対応パターンは8種類で、アーキテクチャ図やフロー図、比較図、ディレクトリツリー図なんかを作れる。 スキルファイル自体はコンパクトに保って、デザインパターンのお手本集は別ファイル（ references/examples.md ）に分けてあります。この「お手本集」が後で話す「育てる」仕組みの核になるんですが、詳しくはデモを見た後に。 HTMLからPNGに変換するCLIツール スキルが生成するのはHTMLファイルです。ブログに貼るにはPNG画像が必要なので、変換ツールを作りました。 uv run html-screenshot --file diagram.html --output diagram.png これだけ。中身は Python + Playwright（Chromium）で、やってることはシンプルです: Chromium をヘッドレスで起動 HTMLファイルを file:// プロトコルで読み込み Tailwind CDN や Material Icons の読み込み完了を待機（ wait_until="networkidle" ） body 要素のスクリーンショットを PNG で保存 デフォルトで 1280×720 の画像が出力されます。HTMLで w-[1280px] h-[720px] と固定サイズを指定しているので、ブラウザのビューポートサイズに関係なく常に同じ結果になります。 実際に使ってみた 基本的な使い方 実際にやった流れを見せます。Claude Code に「3層アーキテクチャのフロー図を作って」と指示すると、スキルが自動で起動して HTML ファイルを生成してくれます。 生成されたHTMLはこんな感じ（抜粋）: <body class="w-[1280px] h-[720px] m-0 p-0 overflow-hidden bg-gray-50"> <div class="w-full h-full flex items-center justify-center p-10" role="img" aria-label="3層アーキテクチャ図"> <div class="w-full max-w-4xl flex flex-col gap-4"> <!-- Presentation Layer --> <div class="bg-blue-100 border-2 border-blue-500 rounded-lg p-6"> <h2 class="text-2xl font-bold text-blue-900">Presentation Layer</h2> </div> <!-- 以下、Business Logic Layer、Data Access Layer と続く --> </div> </div> </body> Tailwind CSS のクラスで全部スタイリングされてるので、HTML が読める人なら「ここの色を変えたい」「この余白を詰めたい」って修正が自分でできるんですよね。 これを CLI で変換すると: uv run html-screenshot --file architecture.html --output architecture.png ぶっちゃけ僕が作るよりいい時がある 使ってて驚いたのが、ベン図とか比較系に関してはすごくいいんですよ。配色のバランス、要素の配置、余白の取り方。Claude は CSS の知識が豊富だから、Tailwind のクラスを適切に組み合わせて整ったデザインを出してくる。 全部が良いわけじゃないです。でも「たまに自分より上手いの出してくる」っていうのがリアルなところで、そういう時は素直にそのまま活用をしています。あとは、何ラリーかして補正すれば大体はいけますね。 うまくいかないパターン 正直に言うと、ダメなパターンもあります。 要素が多すぎる図 。720px の高さに収めないといけないので、10個も20個も要素がある図は厳しい。はみ出すか、文字が小さくなりすぎる。 指示が曖昧な時 。「いい感じの図を作って」みたいなざっくりした指示だと、汎用的すぎるデザインが出てくる。「3層アーキテクチャで、各層にアイコン付きで」くらい具体的に言った方がいい結果が出ます。 あと地味に困るのが Tailwind CDN の読み込みタイムアウト 。ネットワークが不安定な時にたまに起きる。変換ツールは wait_until="networkidle" で外部リソースの読み込みを待つ設計なので、CDN が遅いとそのまま待ち続けちゃう。まあ、再実行すればだいたい解決しますけど。（この辺は環境依存です） スキルを「育てる」: reference フィードバック ここからが今回の記事で一番伝えたいところです。 良いデザインを reference に保存する さっき「デザインパターンのお手本集を別ファイルに分けてある」と書きました。これが references/examples.md で、スキルが図解を生成する時に参照するお手本集です。 やることは単純で、 気に入ったデザインの HTML コードをこのファイルに追記するだけ 。 .claude/skills/diagram-generator-html/ SKILL.md ← スキル本体（Level 2） references/ examples.md ← ここにお手本を追加していく（Level 3） SKILL.md から examples.md へのリンクが既にあるので、ファイルに追記するだけで Claude が次回から参照してくれます。 1つ注意点があって、 SKILL.md から明示的に参照（リンク）されていないファイルは Claude が認識しません 。references/ にファイルを置いただけでは駄目で、SKILL.md 内に [examples.md](references/examples.md) みたいなリンクが必要です。既にリンクがあるファイルに追記する分には問題ないですけど、新しいファイルを追加する場合は忘れずに。 Before/After: reference 追加で出力はどう変わるか ここが核心。reference にパターンを追加すると、実際にスキルの出力がどう変わるのか。 今回は examples.md にまだ入っていない「タイムライン図」で試してみます。 Before（reference にタイムライン図がない状態） 「プロジェクトの開発タイムラインを図にして」と指示。正直、微妙だった。悪くはないんだけど、うちのブログの図じゃない。配色もアイコンの使い方も、プロジェクトで統一しているルールが反映されてない。 After（良いタイムライン図を reference に保存した後） 同じ「タイムライン図を作って」という指示なのに、出てきたものが全然違う。配色もアイコンの使い方もブログのトンマナに合っている。これ初めて見た時、マジで「おっ」ってなりました。しかもここから「ステップを5つに増やして」みたいなカスタマイズもできる。reference のパターンをベースに、さらに調整が効くんですよね。 見比べると違いがわかると思います。reference があると、Claude は「このプロジェクトではこういうデザインが求められている」という文脈を持った状態で図を生成する。指示が同じでも、出力の解像度が上がるんですよね。 reference が増えてもスキル起動コストは変わらない Progressive Disclosure の Level 3 の設計がここで効いてきます。 references/ ディレクトリのファイルは、スキルが起動した時に自動で全部読み込まれるわけじゃないんです。Claude が「必要だ」と判断した時にだけ読み込まれる。だから、お手本パターンを10個追加しようが50個追加しようが、スキルの起動時に消費するトークンは変わらない。 これ、地味だけどかなり重要で。パターンを追加するデメリットがほぼないんですよ。「良いデザインが出たら保存する」をひたすら繰り返すだけでスキルが育っていく。 あと、Git で管理されているので、チームで共有できるのも良い。僕が見つけた良いパターンをコミットすれば、チーム全員のスキルが育つ。「AIに教える」というより「お手本集を充実させる」イメージですね。 正直な現在地 定型的な図解（アーキテクチャ図、フロー図、比較図、ベン図あたり）はかなり使えるレベルになりました。reference にパターンを蓄積するほど品質が安定してきているのは実感があります。 でも、毎回100点のデザインが出るわけじゃない。「たまにいい」が正直なところです。複雑なインフォグラフィックとか、独創的なレイアウトが必要な図はまだ難しい。Figma レベルの自由度はないです。 HTMLだから自力で修正できるのが救いで、「80点のものが出てきたら、残り20点は自分で調整する」くらいの付き合い方がちょうどいい。reference の蓄積が進めば、この80点が85点、90点になっていくんだろうなとは思ってます。トークンを気にしないのであれば、何ラリーかすれば普通に使える図になります。でも、マジの軽微な修正だったらコードを直接修正したほうが良いね。 将来的には完全に図化をAIに丸投げできたらうれしい。でも今はまだその途中で、「育てている最中」っていうのが正直な現在地です。 まとめ 技術ブログの図解作成、Figma で人力でやってた頃と比べるとだいぶ楽になりました。SKILL で HTML 図解を自動生成して、CLI で PNG に変換する。仕組み自体はシンプルです。 でも、この仕組みの本当の価値は「育てられる」ことだと思ってます。良いデザインが出たら reference に保存する。それだけで次からの出力品質が上がる。パターンを追加するコストはほぼゼロ。この成長サイクルが回り始めると、使えば使うほどスキルが育っていく。 完璧じゃないけど、育てていける。みんなも自分のスキルを育ててみない？ ほなまた〜 作ってみよう: 構築手順 ここからは「自分の環境でも作りたい」って人向けの構築手順です。必要なのは3つ: 図解生成スキル （SKILL.md）、 お手本集 （references）、 PNG変換ツール 。 最終的なディレクトリ構成はこうなります: .claude/skills/diagram-generator-html/ ├── SKILL.md ← スキル定義本体（Step 1） └── references/ └── examples.md ← デザインパターンのお手本集（Step 2） SKILL.md がスキルの本体で、references/ 以下がお手本集。PNG変換ツール（Step 3）は別途用意します。この構成が記事前半で説明した Progressive Disclosure の Level 2（SKILL.md）と Level 3（references/）にそのまま対応しています。 Step 1: 図解生成スキル（SKILL.md）を配置する .claude/skills/diagram-generator-html/ ディレクトリを作って、 SKILL.md を配置します。僕が実際に使っているスキル定義をそのまま載せます。 frontmatter（スキルの設定部分）: --- name: diagram-generator-html description: | This skill should be used when the user asks to "HTMLで図を作って", "Tailwindで図解を生成して", "アーキテクチャ図を作成して", "フロー図を作って", "比較図を生成して", or needs a technical diagram for a blog article using HTML and Tailwind CSS. allowed-tools: Read, Write, Bash --- SKILL.md の本体: # Diagram Generator HTML 技術ブログ記事用のHTML図解を生成し、PNG画像に変換します。 ## Supported Patterns | パターン | 用途 | |---------|------| | アーキテクチャ図 | レイヤード、マイクロサービス、イベント駆動 | | フロー図 | プロセス、データ、ユーザーフロー | | 関係図 | ER図、クラス図、シーケンス図 | | 比較図 | Before/After、オプション比較 | | コンポーネント図 | システム構成、デプロイメント | | 概念図 | コンセプトマップ、ツリー構造 | | 同心円図 | 階層構造、抽象度の層、ベン図ライク | | ディレクトリツリー図 | ファイル構成、フォルダ階層、プロジェクト構造 | ## Specifications - **サイズ**: 1280 x 720 px (16:9) - **技術**: HTML5 + Tailwind CSS + Material Icons - **出力**: PNG画像 - **保存先**: `docs/article/[feature-name]/images/` ## HTML作成ルール 1. **固定サイズ**: `<body class="w-[1280px] h-[720px] m-0 p-0 overflow-hidden bg-[背景色]">` 2. **外側padding**: `p-8` または `p-10` 3. **要素間隔**: `gap-4` 4. **Tailwind CDN**: `<script src="https://cdn.tailwindcss.com"></script>` 5. **最小フォント**: `text-sm` (14px) 以上 6. **禁止事項**: JavaScript動的要素、アニメーション、カスタムCSS ## Accessibility - コントラスト比: WCAG Level AA準拠 (4.5:1以上) - セマンティックHTML: `role="img"`, `aria-label` - 色依存の回避: 色 + 形状の組み合わせ ## Color Palette | 用途 | Class | |------|-------| | Primary | `bg-blue-500`, `text-blue-900` | | Secondary | `bg-green-500`, `text-green-900` | | Accent | `bg-orange-500`, `text-orange-900` | | Background | `bg-white`, `bg-gray-50` | ## Workflow ### 1. 情報収集 必要な情報: - 図解タイプ（アーキテクチャ、フロー等） - 含める要素 - 保存先記事ディレクトリ ### 2. HTML生成 基本テンプレート: ```html <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <title>[タイトル]</title> <script src="https://cdn.tailwindcss.com"></script> <link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Material+Symbols+Outlined:opsz,wght,FILL,GRAD@20..48,100..700,0..1,-50..200" /> </head> <body class="w-[1280px] h-[720px] m-0 p-0 overflow-hidden bg-white"> <div class="w-full h-full bg-white flex items-center justify-center p-10" role="img" aria-label="[説明]"> <!-- 図解内容 --> </div> </body> </html> ``` **詳細なパターン例**: [examples.md](references/examples.md) ### 3. ファイル保存 保存先: `docs/article/[feature-name]/images/[ファイル名].html` ### 4. PNG変換 ```bash uv run html-screenshot \ --file docs/article/[feature-name]/images/[ファイル名].html \ --output docs/article/[feature-name]/images/[ファイル名].png ``` ## Validation Checklist - [ ] `<!DOCTYPE html>` 宣言がある - [ ] Tailwind CDN が読み込まれている - [ ] `<body>` に固定サイズクラスがある - [ ] 外側divに `p-8` または `p-10` がある - [ ] JavaScript/アニメーションが含まれていない - [ ] `role="img"` と `aria-label` が設定されている ## Troubleshooting | 問題 | 対処 | |------|------| | PNG変換失敗 | HTMLファイルのパスを確認、`--force`で上書き | | 200KB超過 | HTMLを簡素化、サイズを縮小 | | ディレクトリ不在 | 先に作成してから保存 | ポイントをいくつか補足: description : 日本語の呼び出しフレーズを入れておくと、「図を作って」みたいな指示でスキルが自動発火する allowed-tools : Read, Write, Bash に制限。スキル実行中に余計なツールを使わせないことで動作が安定する HTML作成ルール : 固定サイズ・最小フォント・禁止事項を明記。Claude は「やるべきこと」「やっちゃダメなこと」の両方が明確だと良い結果を出す references リンク : 本体末尾の [examples.md](references/examples.md) が Progressive Disclosure の Level 3 への入り口。 このリンクがないと Claude は references を読みにいかない ので要注意 Step 2: お手本集（references/examples.md）を用意する .claude/skills/diagram-generator-html/references/examples.md にデザインパターンのお手本を配置します。僕の examples.md には7パターン収録されていますが、ここでは2パターン抜粋して紹介します。 アーキテクチャ図パターン Material Icons と色分けで層を区別する縦積みレイアウト: <div class="w-full max-w-4xl flex flex-col gap-4"> <div class="bg-blue-100 border-2 border-blue-500 rounded-lg p-6"> <div class="flex items-center justify-center gap-3"> <span class="material-symbols-outlined text-5xl text-blue-600">desktop_windows</span> <div class="text-center"> <h2 class="text-2xl font-bold text-blue-900">Presentation Layer</h2> <p class="text-sm text-blue-700 mt-1">UI・ユーザーインターフェース</p> </div> </div> </div> <div class="text-center"> <span class="material-symbols-outlined text-5xl text-gray-400">arrow_downward</span> </div> <div class="bg-green-100 border-2 border-green-500 rounded-lg p-6"> <!-- 同様の構造、色をgreen系に変更 --> </div> </div> レイヤー数に応じて色を blue → green → orange の順に使うのがコツ。 フロー図パターン ステップを中央揃えで縦に並べ、ノードの形状でステップ種別を表現: <div class="flex flex-col items-center gap-4"> <div class="bg-green-500 text-white rounded-full px-8 py-4 text-lg font-bold shadow-lg"> 開始 </div> <div class="text-gray-400 text-4xl">↓</div> <div class="bg-blue-500 text-white rounded-lg px-8 py-4 text-center shadow-lg"> <p class="text-lg font-bold">認証情報入力</p> <p class="text-sm mt-1">ユーザーID・パスワード</p> </div> <div class="text-gray-400 text-4xl">↓</div> <div class="bg-red-500 text-white rounded-full px-8 py-4 text-lg font-bold shadow-lg"> 完了 </div> </div> rounded-full が開始/終了ノード、 rounded-lg が処理ノード。この区別だけでフローチャートっぽくなります。 他にも比較図、同心円図、ディレクトリツリー図などのパターンがあります。最初から全部揃える必要はなくて、1〜2パターンで始めて、気に入った出力が出たら追記していけばOK。この積み重ねがスキルを育てることになるので。 Step 3: HTMLからPNGに変換する スキルが生成するのはHTMLファイルなので、ブログに貼るにはPNG変換が必要です。 CLIツール（html-screenshot） 僕は Python + Playwright で自作のCLIツールを使っています。できることベースで紹介すると: オプション 説明 デフォルト --file , -f HTMLファイルから変換 – --html , -H HTML文字列から直接変換 – --output , -o 出力先PNGパス output.png --width , -w 幅（px） 1280 --height , -h 高さ（px） 720 --force , -F 既存ファイルの上書き False # 基本: HTMLファイルからPNGに変換 uv run html-screenshot --file diagram.html --output diagram.png # サイズ指定 uv run html-screenshot --file diagram.html --output diagram.png --width 1920 --height 1080 # HTML文字列から直接変換（ちょっとした確認用） uv run html-screenshot --html "<h1>Hello</h1>" --output test.png 内部処理は4ステップ: Playwright で Chromium をヘッドレス起動 file:// プロトコルで HTML を読み込み wait_until="networkidle" で Tailwind CDN 等の外部リソース読み込みを待機 body 要素のスクリーンショットを PNG で保存 HTML側で w-[1280px] h-[720px] と固定しているので、ビューポートに関係なく毎回同じサイズの PNG が出ます。 代替案: Playwright MCP CLIツールを自作するのが手間なら、 Playwright MCP を使う方法もあります。Claude Code から Playwright のブラウザ操作を直接呼び出せるので、HTML を開いてスクリーンショットを撮る操作が MCP のツールで完結します。 セットアップ方法は別の記事で詳しく書いているので、こちらを参照してください: Playwright MCPで始めるブラウザ自動化｜環境別セットアップガイド CLIツールとPlaywright MCPの使い分け: 観点 CLIツール Playwright MCP セットアップ Python + Playwright パッケージ MCP サーバー設定 安定性 ローカル完結で安定 MCP 接続に依存 トークン消費 少ない ツール定義分の消費あり 汎用性 HTML→PNG 変換に特化 ブラウザ操作全般 「HTML を PNG に変換したいだけ」なら CLI の方がシンプルで安定します。一方で、スクリーンショット以外のブラウザ操作も Claude Code にやらせたいなら Playwright MCP の方が汎用性は高い。自分の用途に合った方を選んでください。 関連ブログ / 参考リンク 図解作成が驚くほど楽に！Claude SkillでSVG自動生成 Claude Code SkillでHTML図解を自動生成！時短テクニック ClaudeでMermaid図作成を自動化！2時間→5分の劇的時短術 Playwright MCPで始めるブラウザ自動化｜環境別セットアップガイド Claude Code 公式ドキュメント（Skills） Playwright 公式ドキュメント ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 図解作成、AIに丸投げしたら「たまに自分より上手い」件 — Claude Code を育てる方法 first appeared on SIOS Tech Lab .

はじめに こんにちは、ビジネスdアプリ開発チームの露口・德原です。 これまでモバイル端末向けに展開してきた「ビジネスdアプリ」の社内報機能に、PCブラウザ版が加わりました。本記事では、その社内報PCブラウザ版の開発についてご紹介します。 ビジネスdアプリについては過去の記事をご覧ください。 ・ サーバレスをフル活用したビジネスｄアプリのアーキテクチャ（前編） ・ サーバレスをフル活用したビジネスｄアプリのアーキテクチャ（後編） 目次 はじめに 目次 社内報機能の概要 主な機能の紹介 リソースを最小限に抑える2つの工夫 フロントエンド：CSS（@media）によるレスポンシブ対応への一本化 バックエンド：既存APIレスポンスに合わせたUI設計 GTMによるログ分離の実装 グラフィカルユーザーインターフェース（GUI）による迅速なタグ管理 高精度なトリガー条件の設定 プレビュー機能 デバイス判定と分析の仕組み 終わりに 社内報機能の概要 ビジネスdアプリの「社内報」は、管理者から従業員へタイムリーな情報共有ができる社内周知用サービスです。単なる掲示板ではなく、従業員に確実に情報を届けて閲覧状況を確認するための機能を備えています。 (画像はPCブラウザ版のものです) 主な機能の紹介 プッシュ通知機能(通知はモバイルアプリ版のみ) 閲覧状況の確認 リマインド機能(通知はモバイルアプリ版のみ) タスクの完了確認 その他にも記事のソート・フィルター機能、公開期限の設定、詳細な権限管理など、投稿管理に欠かせない機能を網羅しています。 今回のPCブラウザ版リリースで、記事を投稿する際はPCを利用し、受け取る側は状況に合わせてPCやモバイル端末で確認するといった事ができるようになりました。 本記事では、主にPCブラウザ版の開発についてご紹介します。 リソースを最小限に抑える2つの工夫 すでに運用していたモバイルアプリ版の社内報に加え、PCブラウザ版を開発するにあたって「いかに新規リソースを作らずに実現するか」という観点でUI/UXの設計しました。 具体的なアプローチは以下の2点です。 フロントエンド：CSS（@media）によるレスポンシブ対応への一本化 1つめの工夫は、PCブラウザ版専用のコードを極力作らないという点です。 通常、PCブラウザ版とモバイルアプリ版でUIが大きく異なる場合、コードを分けることも検討されますが、今回は元々あったモバイルアプリ版（WebView）のコードをベースに開発を進めました。 具体的には、画面サイズに応じて制御するCSSのメディアクエリ（@media）を採用しました。 共通コンポーネントの活用: ベースとなる構造はモバイルアプリ版と共有。 表示の制御: PCブラウザの画面幅を検知し、CSSで上書き調整。 これにより、ロジック部分は基本的に共通化し、スタイル定義の追加中心でPCブラウザ対応を実現しました。 バックエンド：既存APIレスポンスに合わせたUI設計 2つめの工夫は、APIサーバー等のバックエンドリソースもモバイルアプリと共有したことです。 社内報は元々モバイルアプリの1つの機能であり、モバイルアプリでの表示を前提としたAPIを作成していました。このAPIのレスポンスをそのまま活かせるUIをPCブラウザ版でも採用するというアプローチをとりました。 これにより、バックエンド側の開発工数を抑えることができました。 GTMによるログ分離の実装 今回のPCブラウザ版リリースにあたって、モバイルアプリ版と分けてログを収集するため、新たにGoogle Tag Manager（GTM）をベースとした行動ログ収集基盤を構築しました。 Google Tag Manager導入にあたって以下3点のメリットがありました。 グラフィカルユーザーインターフェース（GUI）による迅速なタグ管理 通常、Google Analytics 4（GA4）のイベントを追加・変更するにはソースコードの修正とデプロイが必要ですが、GTMなら管理画面（GUI）上でタグの設定が可能です。例えば開発者以外のサービス企画やマーケティング担当者も、タグの設定(追加・変更・削除)を管理画面（GUI）上で行う事が可能になります。 高精度なトリガー条件の設定 ページ単位の計測はもちろん、特定のURL、ボタンのクリック要素、フォームの送信など、細かな条件を開発不要で設定可能です。 プレビュー機能 ブラウザ上で実際に操作しながら、「どのタグがどのタイミングで発火したか」をリアルタイムでデバッグできます。検証時間を短くする事が可能になります。 デバイス判定と分析の仕組み モバイルアプリ（WebView）版とPCブラウザ版のログを正確に識別するため、以下のロジックを実装しています。 モバイルアプリ版かPCブラウザ版かの判定は、モバイルアプリ内のWebViewコンポーネントかどうかで判断し、 WebViewコンポーネントではない(＝PCブラウザ等である)と判断された場合にPCブラウザ版の行動ログを送信しています。 収集したデータはBigQueryへエクスポートし、分析しています。以下のフィールドを組み合わせて参照することで、モバイルアプリ版かPCブラウザ版かの行動情報を切り分けています。 device.category: 端末の種類（mobile, desktopなど） device.web_info.browser: 利用されているブラウザの種類 GTMを中心とした基盤構築し、モバイルアプリ版とのログ分離を実現しました。これにより運用・検証コスト削減にも繋がっています。 終わりに スマホとPC、どちらでも利用できるビジネスdアプリの社内報の開発についてご紹介しましたが、いかがでしたでしょうか。 私たちはこれからも、ビジネスの現場をより便利に変えていくサービスや機能の開発にチャレンジしていきたいと思います。 これからもビジネスdアプリをよろしくお願いいたします。 ※ 私たちが開発しているビジネスdアプリに興味を持った方は、是非 公式ページ をご覧ください。 今回ご紹介した社内報やその他の機能について、私たちが開発している機能一覧が記載されています。