この記事は 2026 年 8 月 4 日に公開された Guidance for an AI-Powered Studio on AWS を翻訳したものです。 生成 AI は、スタジオのプレミアムコンテンツ制作のあり方を根本から書き換えつつあります。映画品質の画像、動画、音声、3D アセットを生成できるモデルは日々更新されており、それらがもたらすクリエイティブな可能性には期待が高まるばかりです。具体的には、制作期間の短縮、予算内でできることの拡大、アーティストの創造性の解放、そして従来は資金面で実現困難だったストーリーの制作が可能になります。しかし、AI は高品質なコンテンツを自動的に生成する魔法のボタンではありません。AI は、熟練したストーリーテラーが活用することで、より速く、より高品質で、よりコスト効率の良いアウトプットの創出を支援し得る、非常に効率的なツールなのです。しかし、たとえ巧みに使いこなしたとしても、「モデルにはこれができる」と「制作チームがこれを納品できる」との間にはギャップがあり、まさにそこが不明瞭になりやすいポイントです。 AI モデルによるコンテンツ制作は日々容易になっていますが、依然として困難は残ります。どのモデルがどのアセットを作ったかの追跡、タスクの適切なモデルへのルーティング、ソースフッテージ (撮影素材) と生成メディアを共有カタログへの取り込み、予算の超過を伴わないクリエイティブな変更の反映、自社 IP を使った独自モデルの学習、そしてすべてのフレームに追跡可能かつ人間が関与した系譜 (リネージ、コンテンツの来歴) を残すこと——課題は尽きません。これらは制作インフラの課題であり、Amazon Web Services (AWS) はスタジオがクリエイティブな作業に集中できるよう、それらを解決するためのマネージドなビルディングブロックを提供します。 Amazon Web Services は、スタジオがクリエイティブな作業に集中できるよう、 これらの制作インフラの課題を解決するためのマネージドなビルディングブロックを提供します。 本ガイダンスでは、AI-Powered Studio (AI を活用したスタジオ)というコンセプトを紹介します。これは、上記の課題に対処するために設計されたプラットフォームアーキテクチャです。このアーキテクチャは、AI 生成コンテンツから価値を引き出すために必要な 5 つのコアな役割を軸に構成されています。 5 つの C Consistency (一貫性) — キャラクターやブランドにおいて、複数のショット、シーン、番組にわたって同じ見た目を安定して再現・制作できることが求められます。あるカメラアングルから別のアングルに切り替わっても、キャラクターや小道具の連続性を保つことは、視聴者の没入感を損なわないために不可欠です。 Context (コンテキスト) — キャラクターやブランドの一貫性は、一枚のビジュアルが生成される前の段階にあるアイデアやデザインから生まれます。すべてはストーリーから始まるのであって、画像単体からではありません。コンテキストこそが、一貫性を築くための土台です。 Control (コントロール) — フレームの他の部分に影響を与えることなく、正確かつ的を絞った編集ができる能力です。ひとつのオブジェクトを変更するだけでショット全体が再構築されてしまうようでは、アーティストはクリエイティブの主導権を失い、ワークフローは遅く予測不能なものになります。 Compliance (コンプライアンス) — 制作で使用するツールや IP が法的にクリアされていることを保証するには、AI のスピードに対応できるようプロセスの改善が必要です。さらに、IP 所有権の要件を満たすために、コンテンツの来歴を厳密に追跡できるよう拡張しなければなりません。 Cost (コスト) — AI によるコンテンツ生成が従来の方法よりコストがかかるなら、導入するビジネス上の理由はありません。スタジオには、予期しない請求額に膨張しないよう、明確なコスト可視性と支出コントロールが必要です。 本ガイダンスにおけるすべてのアーキテクチャの決定は、これらの役割を果たすためのものです。続くセクションでは、モデル非依存のルーティング、ビジュアル一貫性の手法、構造化されたコンテキスト、来歴の記録、そして統一アセットカタログが、それぞれどのようにこれらの役割の実現に貢献するかを説明します。 AI 対応スタジオが直面する共通の課題 AI 制作は本質的にマルチモデルであり、モジュール型のオーケストレーションが必要 — 最高の動画モデルが最高の画像モデルとは限らず、最高の画像モデルが最高の音声モデルとも限りません。しかもこの状況は常に変化しています。商用 SaaS とオープンソースソリューション間の競争環境 (どちらも頻繁にリーダーシップの入れ替えが発生) は、画期的な機能がすぐにコモディティ化することを意味し、単一のツールに長期的にコミットすることはリスクを伴います。この流動性ゆえに、スタジオは「どのモデルが最良か」という問いに事前に答えようとするよりも、アーティストがその時々で最適なモデルを活用できるようにする方法に注力すべきです。本ガイダンスは、クリエイティブチームがプロバイダーを横断して最適なモデルにアクセスし、パイプラインを書き換えることなく必要に応じてモデルを切り替えるプロセスを効率化する仕組みを提示します。 ML プラットフォームチームなしでの独自モデルの学習 — キャラクターデザイン、環境、モーションスタイルなどのスタジオ独自の IP でモデルをファインチューニングすることは、汎用モデルでは実現できないビジュアルの一貫性を保持することで大きな価値を生みます。しかし、ファインチューニングされたモデルをクリエイターの手に届けるまでの技術的ハードルは高く、GPU 基盤、ML エンジニアリングの専門知識、バージョニング、サービングパイプラインが必要です。クリエイティブワークは本質的に反復的であるため、これは一回限りの英雄的な取り組みであってはなりません。再現可能なセルフサービスの仕組みでなければなりません。アーティストは、チケットを発行したり ML-Ops チームを待つことなく、ファインチューニングをトリガーし、結果を検証し、再学習し、更新されたモデルをデプロイできる必要があります。現状、このワークフローを構築するのは複雑なエンジニアリングプロジェクトです。だからこそ、ファインチューニングはアクセスしやすく使いやすいものでなければならず、AI-Powered Studio はそれをすぐに使える状態で提供する必要があります。 アセットの来歴 (プロベナンス) 管理はデリバリーゲート — スタジオは、AI の使用が自社制作物の著作権が認められなくなるのではないかと懸念しており、コンテンツの来歴を追跡するため、すべてのアセットに対して改ざん不可能な制作履歴の記録 (どのモデル、どのパラメータ、どの入力リファレンス、どの人的修正が行われたか) を強制する手段を模索しています。現状、こうした記録は存在しないか、場当たり的に管理されているに過ぎません。スタジオに必要なのは、事後に再構成するのではなく、アーティストの作業中に自動的かつ強制的に記録が行われる仕組みです。来歴管理が手動プロセスであればスケールしません。クリエイティブプロセスに内在していなければならないのです。だからこそ、制作の一部として来歴を扱うガバナンスレイヤーが不可欠です。 コンテンツのアクセシビリティ — 実写制作では、セットで撮影されたフッテージ (デイリーズ／ラッシュ、プレート／実写撮影素材、リファレンスフレーム／基準フレーム) が生成され、下流の AI ワークフローがそれを活用する必要があります。プレートのライティングに合った新しい環境を生成したり、AI キャラクターを実写シーンに合成したりするには、そのフッテージにアクセスできなければなりません。ソース素材が生成出力とは異なるシステムにある場合、アーティストはカタログの照合やファイルの移動に時間を浪費し、制作に充てる時間が失われます。だからこそ、安全でアクセス可能な場所にコンテンツを集中させることがプロセスの基盤となる必要があるのです。 プロダクションスケールでのワークフロー管理 — 1 つの番組は 1 つの生成リクエストではなく、映画、シーズン、エピソード、部門、レビューサイクルにまたがる数百から数千のリクエストによって作られます。スタジオには構造化されたプロジェクト状態、ロールバック付きバージョニング、依存関係追跡、承認チェーンが必要です。生成レイヤーはこれらのシステムの外側に存在するのではなく、それらに接続されるべきです。これが、ワークフローの各ステップが同一のマネージドプラットフォームを経由すべき理由です。 AI 支援制作の反復的な性質 — クリエイティブプロセスは本質的に反復的です。1 回の生成で納品可能なアウトプットが得られると期待すべきではありません。AI を活用した制作現場からのフィードバックによると、チームは 1 ショットあたり平均 2 〜 10 個の異なる AI モデルを利用しています。複数回の処理、複数のモデル、複数回の生成はコンテンツ制作プロセスの一部です。だからこそ、プラットフォームはこの反復をネイティブにサポートする必要があります。処理をまたいだバージョンの追跡、ある処理は画像モデルに通し次の処理は動画モデルに通すといった柔軟なルーティング、そして手作業の記録管理に頼ることなくすべての来歴を一貫して維持できる仕組みが求められます。 これらの課題は複合的です。モデルルーティングを解決しても来歴管理が未解決であれば、制作スピードは上がってもマネタイズできないリスクを抱えます。モデルの学習を解決してもアセット管理を解決しなければ、ファインチューニング済みモデルが生成したアウトプットを誰も見つけられません。最大の価値は、これらを単一のプラットフォーム上で、差別化に繋がらない運用負荷なしにスケールするインフラの上でまとめて解決することにあります。 AI-Powered Studio：コンセプチュアルアーキテクチャ AI-Powered Studio の中核は、 Amazon API Gateway 、 AWS Lambda 、 Amazon DynamoDB などのサービスを活用したサーバーレスのオーケストレーションアプリケーションです。クリエイターや管理チームがアプリケーションにアクセスできるようにする Web UI レイヤーが構築されていること、またモデル呼び出しを処理する推論エンジンレイヤーが利用可能であることを前提としています。このアーキテクチャを特徴づけるのは、生成 AI 制作特有の要求に踏み込んでいる点です。具体的には、複数のモデルバックエンドへのルーティング、学習と推論の疎結合な受け渡し、そしてドキュメントの欠如が納品の障壁にならないよう来歴を自動的に記録する仕組みです。以降のセクションでは、これらの設計判断について詳しく説明します。 図 1: AWS 上の AI-Powered Studio のリファレンスアーキテクチャ 設定によるモデル非依存のルーティング AI-Powered Studio は、ルーティングレイヤーで2つの目的を果たします。第一に、異なるモデルバックエンドに対してアーティストやパイプラインがやり取りの方法を統一する、共通の API サーフェスとのインターフェースを提供します。モデルへのアクセスは Amazon Bedrock 経由、サードパーティ API 経由、またはセルフホストのエンドポイント経由のいずれでも可能です。プラットフォームが認証方式、パラメータ仕様、出力形式の違いを吸収するため、あるプロバイダーから別のプロバイダーへの切り替えにあたって、その上に構築されたクリエイティブツールを変更する必要はありません。第二に、最適なモデルが明確なタスクタイプに対してはオプションの自動ルーティング (例：テキスト分析は常に LLM にルーティング) を可能にしつつ、クリエイティブな判断が重要な場合にはアーティストがモデルを明示的に選択することも可能にします。どちらの動作もアプリケーションコードではなく設定により制御できます。 AWS AppConfig を使用すれば、モデルごとのランタイム設定 (パラメータ、エンドポイントターゲット、選択ロジック) をマネージド設定として保持でき、コード変更なしにデプロイし、問題が発生した場合は安全にロールバックできます。これはガバナンスの仕組みでもあります。プロダクションリーダーシップに、クリエイティブの速度を制限することなく、モデルの利用可否、許容されるパラメータ、ルーティングタスクの可視性と制御を提供します。 これにより、モデルの切り替えは開発リリースではなく、設定のデプロイで実現できます。カタログへの新モデルの追加、特定のタスクタイプの任意のモデルへのルーティング、手動選択用の新モデルの有効化は、スプリント単位ではなく当日中に実装できます。モデルリリースのペースを考えると、先月の最先端を使うか今月の最先端を使うかは大きな差になり得ます。一般的な実装では、ルーティングは以下の 3 種類のバックエンドに分岐します。 Foundation language models (基盤言語モデル) — スクリプトをシーンに分解し、ショットを記述するために使用されます。Amazon Bedrockは単一の API を通じて高性能な基盤モデル (FM) の選択肢を提供するため、プラットフォームは GPU インフラのプロビジョニングや管理を行うことなく、タスクに最適な基盤モデルにアクセスできます。Amazon Bedrock はリクエスト量に応じて弾力的にスケールするため、開発中の少数のスクリプト分解からエピソード制作の繁忙期における数千件の処理まで、キャパシティプランニング、リザーブドインスタンス、スプリント間のアイドル GPU なしに対応できます。 画像、動画、音声、3D 生成 — AWS パートナーやモデルアグリゲーター (例：fal.ai) を通じて、統一された API 呼び出しで生成モデルにアクセスできます。生成された出力は顧客の Amazon Simple Storage Service (Amazon S3) バケットに直接書き込まれるため、他のすべてのアセットと同じ下流のアセットパスに合流します。 セルフホストモデル — AWS は、 Amazon Elastic Compute Cloud (EC2) 、 Amazon SageMaker 、 AWS Deadline Cloud など、GPU ベースのインフラ上でオープンソースおよびカスタムモデルをホストする複数の方法を提供しています。Deadline Cloud はバッチコンピューティングおよびレンダリング管理を簡素化するフルマネージドサービスであり、スタジオ固有の IP でファインチューニングされたモデルをマネージド GPU 上で推論実行することが可能です。この手法は、学習データとモデルをスタジオの管理下に置く必要があるタスクに適しています。ComfyUI などの業界標準ソフトウェアは、EC2 インスタンス や Amazon Elastic Kubernetes Service (EKS) コンテナにデプロイでき、アプリケーションレイヤー (アーティストインターフェース) またはコンテンツ生成サービスオーケストレーターとして機能し、プロフェッショナルチームにきめ細かい制御を提供します。 図 2: バックエンドの生成タスクに利用可能な複数のモデルを表示する、モデル選択・ルーティングインターフェースの例 ビジュアル一貫性の実現：ファインチューニングとリファレンスコンディショニング 制作における生成物は、確立されたクリエイティブビジョンと一貫していなければなりません。承認済みのキャラクターデザイン、環境のスタイル、モーション言語と、すべてのショットで一致している必要があります。事前学習済みモデルでこの一貫性を実現する主要な手法は 2 つあり、よく設計された AI-Powered Studio は、どちらか一方を優位に位置づけるのではなく、補完的なワークフローの選択肢として両方をサポートすべきです。 Low-Rank Adaptations (LoRA) によるファインチューニング は、軽量なモデル特化の学習を行い、モデルに対象の分散的な概念を与えるアーティファクトを生成します。優れたアイデンティティ LoRA とは、モデルが単に開始画像を参照するのではなく、対象の完全な 3D アイデンティティを内在化していることを意味し、これにより新しいポーズ、ライティング条件、構図にわたって一貫した生成が可能になります。トレードオフとして、ファインチューニングにはこれらのアーティファクトを生成・バージョン管理するための初期コンピュートリソース、時間、ML オペレーションの専門知識が必要です。Amazon SageMaker AI がトレーニングインフラを管理し、生成された LoRA アーティファクトをバージョン管理されたアセットとして Amazon S3 に保存します。SageMaker AI や Deadline Cloud などの AWS コンピュートサービスが、これらのアーティファクトを使用したオンデマンド推論を可能にします。 リファレンスコンディショニング は、推論時にリファレンスとなるビジュアルや画像をモデルに渡す手法です。リファレンスコンディショニングは、画像生成・動画生成の両方において一貫性を実現する補完的なアプローチを提供します。モデルに対象を学習させるのではなく、アーティストが承認済みのリファレンス画像をアセットカタログから取得し、プロンプトとともに生成モデルに渡します。メリットとしては、初期コストの低減 (学習が不要)、本番投入までの時間短縮、完全な監査可能性 (すべての入力画像が来歴管理チェーンで追跡可能)、そしてモデルが学習した近似値ではなく実際のリファレンスを見ているため、繰り返し登場するキャラクターやオブジェクトに対してより正確なディテールの再現が期待できる点が挙げられます。トレードオフとしては、リファレンスコンディショニングは生成リクエストごとにより多くのコンピュートリソースを消費します。モデルが各呼び出し時にリファレンス画像を処理する必要があるためです。対照的に、LoRA ベースの生成はトレーニング完了後の推論あたりのリソース消費が大幅に少なくなります。 Video Retrieval-Augmented Generation (v-RAG) と呼ばれるもう一つのオプションは、動画固有の手法で、Retrieval-Augmented Generation (RAG) を使用してインデックス化されたコンテンツからモデルが自動的にリファレンスビジュアルを選択し、推論時に生成モデルに渡します。 実際の運用では、ファインチューニングとリファレンスコンディショニングのどちらを選ぶかは、技術的な優劣ではなく、クリエイティブワークフロー上の判断です。数百ショットに登場する主要キャラクターには LoRA を使い (トレーニングコストを償却)、登場頻度の低いサブ要素にはリファレンスコンディショニングを使うプロダクションもあるでしょう。監査可能性のメリットから v-RAG を主に活用するケースもあるかもしれません。AI-Powered Studio は両方をシームレスにサポートすべきです。ファインチューニングの ML オペレーションの複雑さを使いやすいインターフェースの背後に抽象化し (アーティストが MLOps チームなしでも LoRA を作成できるように)、同時にアセットカタログと統合された堅牢なリファレンス画像検索パイプラインも提供する。プラットフォームがこの判断をクリエイティブな選択にするのです。​ ショット一貫性のための構造化コンテキスト 構造化されたシーンコンテキストは、ビジュアル一貫性のアプローチが正しいロケーション、正しい衣装、正しい小道具、正しいライティングの下で成果物を生成することを保証します。アセット、環境、キャラクターのビジュアル一貫性にとどまらず、シーン内のショット一貫性 (アングル、ライティング、ビジュアルランゲージなど) を実現するには、コンテキストを最優先の設計課題として構造的なアプローチで扱う必要があります。本ガイダンスでは、構造化された分解によるアプローチを推奨します。スクリプトまたはストーリーから始め、それをシーンに、さらにショットに分解します。各シーンについて、関連するロケーション、キャラクター、小道具を特定します。これらの要素はそれぞれ、システム内の再利用可能なコンテキストオブジェクトとなり、リファレンス画像、テキスト記述、制約条件を備え、それらが関わるすべての生成リクエストに情報を提供します。 この階層の各レイヤーにはリファレンス素材が必要です。キャラクターには、外見、衣装、ヘアスタイル、歩き方、仕草、表情の幅といった側面をカバーする詳細なビジュアル・テキスト記述が必要な場合があります。小道具には、サイズ、重さ、素材、スタイルなどの記述が求められます (例：「緑色の金属製シャベル、ハンドル約 24 インチ」)。ロケーションには、ライティングリファレンス、カラーパレット、空間的な位置関係が必要です。このコンテキストが精密かつ構造化されているほど、それを共有するすべてのショットにわたって生成物の一貫性が高まります。ビジュアルリファレンスの作成は、スクリプトから詳細を抽出し画像を自動生成することで自動化できるケースもあります。一方で、アーティストやデザイナーがプラットフォーム内でこれらの詳細を定義し、画像生成を主導するインプットを行うケースもあります。どちらの方法を使うかはクリエイティブな判断であり、堅牢なプラットフォームは両方の方法をサポートすべきです。 コンテキストがプラットフォーム内で決定・記録されれば、ショット、シーン、エピソード、さらにはシーズンをまたいだ一貫性の確保がより容易になります。すべての生成リクエストが関連するコンテキストを自動的に継承します。「シーン 4 のショット 12」に対するリクエストは、そのシーンのロケーション記述、登場するキャラクター (ビジュアルおよび行動に関する完全な記述を含む)、関連する小道具を自動的に取得し、アーティストがそれらを再指定する必要はありません。 AI-Powered Studio のアーキテクチャは、3 つのレイヤーすべてをサポートします。学習されたビジュアルアイデンティティのためのモデルカスタマイゼーション、根拠のあるディテール精度を実現するためのリファレンス検索、そして物語と環境の一貫性のための構造化されたプロジェクト状態管理です。 ワークフローの副産物として取得される来歴 すべてのアセットがどのように作られたか (どのモデル、どの入力、誰の編集) を正確に把握しておくことは、納品時に重要です。この詳細な記録は、法務・コンプライアンス担当チームに対し、契約上のコンプライアンスと利用可能性を評価するために必要な情報を提供します。本アーキテクチャは、その記録を作業の副産物として自動的に生成するものであり、アーティストが締め切りのプレッシャーの中で忘れたり省いたりしがちな、独立した工程にはしません。これこそが、コンテンツの来歴とコンテンツの主権が存在する場所であり、すなわち、自社の制作が承認されたツールを用い、追跡可能なプロセスに従ったことを証明できる能力に他なりません。 本アーキテクチャは、生成時に自動的に取得される不変の来歴証跡を DynamoDB に保存します。すべてのアセット記録は、その完全な系譜を保持します。すなわち、どのモデルを、どのバージョンで、どのパラメータで、どの入力参照をもとに用い、どの人間による修正が適用されたか、です。このメタデータは生成時、つまり API 呼び出しの時点で付与され、個別のロギング工程を必要としません。来歴がクリエイティブ・ワークフローの副産物であり手作業によって後から再構築されるものではないため、専任の人員を割くことなく 1 シーズンにわたる数千点のアセットへとスケールし、クリエイターに追加の時間や労力を求めることもありません。 エージェントは、来歴が適切に取得・記録され、一貫してセキュアに保たれることを担保する優れた手段です。Amazon Bedrock AgentCore では、エージェントにその目的と振る舞いを定義する指示を与え、次に特定のツールやリソースへと接続します。これにより、単一のエージェントが、システム間に独自のコードを用意することなく、自社のランドスケープ全体を横断して推論できるようになります。同時に AgentCore では、エージェントが実行できる内容を制約するガードレールとポリシーを設定できます。その結果として得られるのは、スタック全体にわたって作業をオーケストレーションできるだけの能力を備えながらも、明示的に許可したアクションとデータのみに限定されたエージェントです。 図 3: 生成アセットの監査証跡 (モデル、パラメータ、入力リファレンス、人間による編集) を示す来歴 (プロベナンス) と系譜 (リネージ) のビュー ソースフッテージと生成アウトプットのための統合アセットカタログ AI 生成は、ソース素材を直接参照できるときに最も効果を発揮します。「このプレートの照明に合わせて新しいカメラアングルを生成する」といったリクエストでは、そのプレートがメタデータを備えた第一級のアセットであり、生成物と同じインターフェースで検索でき、同じ識別子でアドレス指定できる必要があります。統合カタログは複数の原則を同時に満たします。すなわち、参照素材をあらゆる生成リクエストからアクセス可能にすることで一貫性を実現し、アセットをそれが属するシーンやプロジェクトに紐付けることでコンテキストを提供し、さらにソースフッテージと派生物とのあいだの系譜を維持しつつ、どのアセットが利用承認済みかを制御することで、コンプライアンスを支えます。 本アーキテクチャは、ソースフッテージと生成メディアを単一のアセット管理サービスに格納します。オンセットのフッテージは専用の Amazon S3 インジェストバケットにアップロードされ、そこでハンドラが識別子とカメラメタデータを、生成物が格納されるのと同じ DynamoDB ベースのカタログに登録します。「シーン12、テイク 3」を検索するアーティストは、オリジナルのプレート、AI が生成した背景差し替え、合成結果、そしてバージョン管理されたすべてのイテレーションを一か所で見つけることができ、そのすべてにわたって共通の系譜が保たれています。 ゼロから構築することなく本番運用品質のアセット管理レイヤーを求めるスタジオ向けには、AWS パートナーが、このパターンへの API レベルでの統合を提供するアセット管理ソリューションを提供しています。 デジタルコンテンツ制作ツール (DCC ツール) との統合 従来のコンテンツ制作ワークフローは、Maya、Blender、Houdini、Cinema 4D、Nuke、DaVinci Resolve、Adobe Creative Suite をはじめとする、業界標準のデジタルコンテンツ制作 (DCC) ツールに依存しています。アーティストはこれらの環境において長年にわたる身体化された技能と専門性を培っており、ツールを捨てて新しいインターフェースへの乗り換えを強いるような AI プラットフォームは、導入を遅らせ、クリエイティブなアウトプットを制限する摩擦を生み出します。AI-Powered Studio はこれらの環境と統合し、エージェントを人間のメンバーと並ぶ協働的なクリエイティブチームの一員として扱うことで、それらの価値をさらに引き出します。 既存のコンテンツ制作ツールの多くは、現在では Model Context Protocol (MCP) をサポートするか、エージェント的な連携を可能にする堅牢な API を備えています。開発者が従来のコーディングと GUI ベースのツールを組み合わせられるのと同じように、スタジオプラットフォーム上の AI エージェントは、アーティストが使い慣れた環境のなかで彼らと並んで作業できます。エージェントは Blender や Houdini の中に直接プロジェクト構造、シーン、アセット階層を構築したり、完成した作業をプラットフォームのカタログへ取り込んだりでき、アーティストは GUI を通じて指示やフィードバックを与えます。ディレクターがシーンを自然言語で記述すると、プラットフォームがそれを複数のモデルにまたがる生成タスクへと分解し、出来上がったアセットを、アーティストが仕上げられる状態の DCC プロジェクトファイルへと送り込む——しかもアーティストがファイルを手動でダウンロード・リネーム・インポートする必要は一切ない、といったことも可能になります。同様に、アーティストが使い慣れたツールで自身の作業を完了してプラットフォームへエクスポートし直すと、統合レイヤーがそのハンドオフを来歴チェーンの一部として自動的に記録します。この系譜記録は、作業が AI 生成と従来のアーティストの手仕事とのあいだを流動的に行き来する場合でも、制作の各構成要素がどのように作られたかを反映します。 プラットフォームを構築するビジネスケース 専用の AI コンテンツ制作プラットフォームを構築することは一つの投資であり、しかも時間とともに複利的に価値を増していく投資です。個々の SaaS ツールは生成という課題をうまく解決しており、その多くは一貫性のためのインフラ、プロジェクトの文脈的な状態管理、きめ細かなクリエイティブ制御を、それぞれの境界の内側で提供しています。プラットフォームというアプローチは、その土台の上に立ち、これらの機能を単一のワークフローへと結びつけることで、コンプライアンス、来歴追跡、コストガバナンスを、後付けではなくネイティブな機能として実現します。その結果として得られるのは、クリエイティブな野心とともに成長していくシステムであり、タスクに最適なツールを統合する柔軟性を与えつつ、インフラを自ら所有することによってのみ得られる一貫性と制御を維持できるのです。 コスト： AI を活用したコンテンツ制作を模索している組織は、特定のワークフロー、とりわけプリビジュアライゼーション、コンセプトアート、環境生成、反復的なアセット開発において、測定可能なコスト削減を報告しています。しかしそうした削減は、コストが可視化され、制御可能である場合にのみ実現します。アーティストが計算コストへのフィードバックなしに反復を重ねる「暴走する再生成 (runaway regeneration)」は、AI が約束する削減効果を蝕みかねません。プラットフォームは、コストの透明性を提供しなければなりません。すなわち、生成にどれだけのコストがかかるかをプロジェクト単位・モデル単位・タスク単位で可視化し、スタジオが十分な情報に基づいてクリエイティブ上・予算上の意思決定を行えるようにする必要があります。専用プラットフォームへの先行投資はコストセンターではなく、コスト規律を保ちながら削減効果を獲得し、持続させるための仕組みなのです。 複利的に積み上がる効率性の向上： 純粋な生成コストにとどまらず、統合プラットフォームは、ばらばらのツールをつなぎ合わせることに伴う「統合税」を取り除きます。すなわち、インターフェース間のコンテキストスイッチ、モデルの出力と制作パイプラインとのあいだの手作業による受け渡し、重複したアセット管理、そしてベンダーが API を更新するたびに壊れる独自の統合を保守するために費やされるエンジニアリング時間、といったものです。これらの非効率性は、いずれも実際の労働コストを伴います。専用プラットフォームは、こうした問題を永続的に回避し続けるのではなく、構造的に取り除きます。 コンプライアンス： 自ら制御するプラットフォーム上でコンテンツが生成され、来歴が自動的に副産物として取得されることで、法務・コンプライアンス担当チームに対して、すべてのアセットがどのように作られたかについての完全な可視性を提供できます。プラットフォームは人間の意思決定を記録し、系譜を辿り、すべてのソースを文書化します。この透明性により、チームは第三者の SaaS 利用規約に依存することなくコンプライアンスを評価できるようになります。 コントロール： AI が生成したコンテンツが制作パイプラインに入ってくるにつれ、スタジオは、どのモデルを使うか、それらをどのようにパラメータ設定するか、そしてどのようなコンテンツを生成するかについて、中央集権的な制御を必要とします。専用プラットフォームは、それぞれ独自のアクセスモデルと利用規約を持つ、ばらばらの SaaS サブスクリプションの寄せ集めにガバナンスを後付けしようとするのではなく、そうした制御の面 (監査証跡、モデルの承認、利用ポリシー、ガードレール) をネイティブに提供します。 モデルの移り変わりに対する将来への備え： 生成 AI の市場は急速に変化しており、今日の有力なベンダーが、一年のうちに買収されたり、提供終了になったり、他に追い抜かれたりする可能性があります。自ら所有するプラットフォームであれば、自社のワークフロー、学習データ、来歴記録、アセットカタログは、どの単一モデルの盛衰にも左右されずに存続します。その時々で最良のワークフローを採用しつつ、それに縛られることがなくなるのです。 ISV のツールには価値がある、置き換えるのではなく統合する： ここまで述べてきたプラットフォーム構築の議論は、Runway、Luma、fal.ai、ComfyUI といった専門的な生成 AI サービスの価値を少しも損なうものではありません。これらのツールは、自らの領域において際立って優れています。画像・動画・3D 生成の最先端を押し広げており、個々のスタジオには到底再現できない規模でモデル研究に多額の投資を行っています。AI-Powered Studio は、複数のプラットフォームを互いに結びつけ、それらすべてに対して同時にガバナンスを提供するレイヤーです。これらの ISV の多くは堅牢な API と連携ポイントを提供しており、それらを自社のプラットフォームに組み込むことで、プラットフォームの能力はさらに広がります。すなわち、彼らの最高水準の生成能力を、来歴管理、ガバナンス、アセットカタログで包み込み、その成果を一か所に集約して手にすることができるのです。プラットフォームはこれらのツールと競合するものではありません。むしろ、それらを本番制作で使えるようになる理由そのものなのです。 この能力を今のうちに築いておくスタジオは、より多くのコンテンツを、より高い品質で、従来の何分の一かのコストで制作できる立場に立てます。しかも、作品を実際に世に送り出すために欠かせない一貫性・文脈理解・コントロール・コンプライアンス・コスト管理をきちんと備えた形で実現できるのです。 はじめるには ここまで説明してきたアーキテクチャは、一般提供されている AWS サービスを使用しており、そのパターンは、AI を制作プロセスに組み込んでコンテンツを生み出すあらゆるスタジオに適用できます。唯一の決まった実装方法があるわけではありません。最適な道のりは、チームの技術的な習熟度、制作規模、そしてスケジュールによって異なります。 ＜カスタム構築プラットフォーム＞ AWS およびパートナーは、メディア & エンターテインメントと ML エンジニアリングの豊富な経験を持ち、ランディングゾーンのセットアップから本番デプロイメントまで、ワークフローに合わせたカスタムプラットフォームの設計と構築をサポートできます。 AWS Professional Services AWS Systems Integrator Partners ＜マネージドプラットフォーム＞ AWS パートナーは、これと同じ AWS サービス上に構築されたフルマネージドのソリューションも提供しています。協働型のワークスペースとモデルに依存しない生成機能をすぐに使える製品として手に入れられるため、クリエイティブな作業そのものに集中できます。 これらのパートナーとの連携に関する推奨や支援、あるいはプラットフォーム構築に向けた追加のガイダンスについては、担当の AWS アカウントチームにお問い合わせください。 多くのスタジオは、上記の両方のアプローチを組み合わせています。すなわち、進行中の制作をすばやく前進させるためにマネージドプラットフォームを採用しつつ、時間をかけて独自の構成要素 (カスタムモデルや特注のワークフロー) に投資していく、という進め方です。 まとめ 生成 AI を取り巻く状況はめまぐるしく動いています。モデルは絶えず進化し、新しいプロバイダーが次々と現れ、クリエイティブチームはエンジニアリングの開発サイクルを待つことなく、すばやく導入したいと望んでいます。本ガイダンスで示すアーキテクチャパターンは、生成 AI をビジネス上の有効な選択肢たらしめる諸原則をしっかりと堅持しながら、そのスピードを御しやすいものにします。すなわち——あらゆるフレームにわたってブランドアイデンティティを保つ Consistency (一貫性) 、すべての生成を構造化されたクリエイティブな意図に根づかせる Context (コンテキスト) 、アウトプットに対するきめ細かな権限をアーティストに与える Control (コントロール） 、来歴を追跡し、承認されたツールの使用を保証する Compliance (コンプライアンス) 、そして AI を暴走する支出ではなく経済的に成り立つものに保つ Cost (コスト) 規律 です。モデルの差し替えをリリースではなく設定変更で行い、クラスターを運用することなく自社の IP で学習させ、余計なプロセスを足すことなく生成された全フレームを追跡可能に保ち、アーティストがソースフッテージと AI の生成物を同じ場所で見つけられるようにする——そのすべてが、これら 5 つの目標のために機能します。 AI-Powered Studio は一つの概念的なアーキテクチャであり、単一の製品ではありません。ここで述べたパターンは、AWS 上で AI を使った制作に乗り出す準備ができたあらゆるチームが利用でき、AWS パートナーがそこへ到達するお手伝いをします。これらの構成要素をどのように組み上げるかは、スタジオごとに固有のものになります——どのモデルへルーティングするか、アセットカタログをどのように構成するか、納品要件がどの程度の来歴の粒度を求めるか、といった点です。原則は共有されるものです。しかし、その実装はあなた自身のものなのです。 参考リンク Amazon Bedrock Amazon SageMaker AI AWS Deadline Cloud Amazon EventBridge AWS AppConfig Amazon API Gateway WebSocket APIs Amazon DynamoDB Policy in Amazon Bedrock AgentCore 寄稿者 Brandon Lindauer, Senior Specialist Solutions Architect, Media & Entertainment Sean Wallitsch, Senior Specialist Solutions Architect, Visual Computing Scott Cler, Senior Industry Specialist, Media & Entertainment Stephen Oliver, Senior Industry Specialist, Media & Entertainment Lee Millstein, Principle GTM Specialist, Media & Entertainment Zach Willner, Senior Partner Solutions Architect, Media & Entertainment Jason O’Malley, Senior Partner Solutions Architect, Media & Entertainment Dan Hawks, Principle Partner Development Specialist, Media & Entertainment ​ AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 本記事は、 Guidance for an AI-Powered Studio on AWS を翻訳したものです。翻訳は Solutions Architect の王、金目が担当しました。 ​

はじめに こんにちは！ KINTO開発部 KINTOシステム開発G マスターメンテナンスツール開発チーム、技術広報部兼務、Osaka Tech Lab 所属の high-g（ @high_g_engineer ）です。フロントエンドエンジニアをやっています。 以前、社内で開催しているフロントエンド勉強会について紹介しました。 https://blog.kinto-technologies.com/posts/2025-06-30-frontend-study-group/ あれから勉強会は続き、2026年10月で第91回を迎えました。 今回はその中で、2026年8月〜9月に全5回で実施した 『HTML解体新書』の輪読会 について紹介します。 正直なところ、書籍の輪読会はフロントエンド勉強会では前例がなく、とりわけ、分厚い技術書の輪読会となると、「途中で失速しがち」「ただ読み上げるだけの会になりがち」という印象があり、少しハードルを高く感じていました。 実際、私自身も前職で同じ本の輪読会を経験したとき、内容を理解しないまま読み進めるだけの会になってしまった苦い思い出があります。 ですが、今回は最後まで走り切れたうえに、参加者全員が前のめりに議論する場になりました。 この記事では、その経緯と進め方、うまくいった理由などをまとめます。 題材にした書籍 https://www.borndigital.co.jp/book/25999/ 『HTML解体新書 ―仕様から紐解く本格入門』は、HTMLの仕様（HTML Standard）をベースに、各要素の意味や使い方、アクセシビリティとの関係を丁寧に解説した書籍です。 なぜHTMLの輪読会をすることになったのか 「次に何をやるか」をみんなで話し合った 輪読会を始める直前、勉強会ではTSKaigi 2026のセッション動画をみんなで視聴していました。ただ、最近のフロントエンド勉強会はTypeScriptの型の話に寄りがちな内容になっていて、動画を見るだけの会が続いていたこともあり、「もう少し現場に寄り添った勉強会にしたい」と考えていました。 そこで7月に2回ほど時間を取り、参加者が所属する各チームで実際に起きているフロントエンドの課題をヒアリングしました。 すると、チームは違っても次のような悩みが共通して挙がりました。 デザイナーとの協業の進め方に課題がある UI / UXに関する知識をもっと伸ばしたい アクセシビリティを最終的にコードへどう落とし込むか、どう周囲を巻き込むか キーワードは「情報設計」 議論を重ねるうちに見えてきたのが、「 情報設計 」というキーワードでした。 勉強会で立てた仮説はこうです。 正しく情報設計されているUI ≒ 正しくマークアップされている ≒ Webアクセシビリティを満たしている デザイナーと協業するうえでも、アクセシビリティを満たしたコンテンツを作るうえでも、土台になるのはHTMLの正しい理解です。 「HTMLの知識を強化することが、情報設計の理解につながり、ひいてはフロントエンドの全チームに共通する課題の解決につながるかもしれない」と考え、まずは h1 〜 h6 を正しい順序で使うという基礎的なレベルから理解し直そう、という結論になりました。その教材としてうってつけだったのが『HTML解体新書』です。 いきなり始めず「本を紹介する会」を挟んだ とはいえ、この本は全352ページというなかなかの厚さです。いきなり「来週から輪読会をやります」と言うと、参加のハードルが一気に上がってしまいます。 一方で「みんなの準備が整ったらやろう」では、いつまでも始まらない可能性が高いです。 そこで、まずは すでに本を持っている人に持参してもらい、どんな本なのかを紹介する会 を一度挟みました。 この会で中身をパラパラと眺めたことで「とりあえず買って一読してみます」「今Kindleで買いました」という声が出て、その場で進め方のルールも決めることができました。 また、マネージャーの承認をもらい、東京（室町）と大阪のオフィスに1冊ずつ会社で書籍を購入できました。 ただ、ふたを開けてみると多くの参加者が自分で購入していて、「会社で買わなくても、みんな持っていたかもしれない」というくらいでした。 輪読会の進め方 ルール ルールはシンプルにしました。 参加者はできる限り事前に読んでくる（ もちろん、読めなくても大丈夫 ） 説明担当は担当箇所を事前に精読し、当日に説明する（ 説明方法はおまかせ ） 書籍は会社購入分を貸し出し可（個人での用意もOK） 「読めなくても大丈夫」と明言しておくことで、担当以外の人も気軽に参加できるようにしています。 1回（約1時間）のタイムテーブル 時間 内容 10〜30分 担当者が担当箇所をざっくり説明 20〜30分 全員で感想や気になったことを話す 3分 次回の担当決めルーレット 次回の担当は、Claude Artifactsで作ったルーレットで決めました。ちょっとしたゲーム感覚があり、「誰になるかな」と盛り上がるポイントでもありました。 範囲は「主要な節だけ」に絞った 全章を読むと長期戦になってしまうため、CHAPTER 3の要素解説から、特に業務に関わりが深い5つの節に絞りました。 回 開催日 範囲 担当 第1回 8/7 セクション 花輪さん 第2回 8/28 グルーピングコンテンツ 三上さん 第3回 9/4 テキストレベルセマンティクス 齋藤さん 第4回 9/11 フォーム その1 high-g 第5回 9/18 フォーム その2 溝口さん お盆や私の休暇で何度かスキップを挟みましたが、当初の見込みどおり5回で完走できました。 アクセシビリティの有識者が参加してくれた 今回の輪読会で大きかったのが、社内のアクセシビリティの有識者である 辻さん 、 守谷さん が参加してくれたことです。 本に書かれている内容に対して「実際のスクリーンリーダーではこう読み上げられる」「昔はこう使われていた」といった、 本の一歩先の知見 をその場で補足してもらえたことで、議論の質が大きく上がりました。 各回の様子 各回とも、担当者が本の内容をなぞるだけでなく、独自の切り口でテキストベースのまとめを作ってきてくれました。ここでは各回で印象に残ったトピックをいくつか紹介します。 第1回：セクション section / article / aside / nav といったセクショニングコンテンツや、 header / footer がランドマークになる条件などを扱いました。 印象的だったのは、書籍の刊行と同じ2022年に アウトラインアルゴリズムがHTML Standardから削除されている ことです。 https://github.com/whatwg/html/pull/7829 現在は、 section で囲んでも見出しレベルは上がらず、 h1 〜 h6 の数字で決まります。 また、「Reactアプリケーションでは、最終的にレンダリングされたHTML全体を目にする機会がほとんどありません。セクション構造が正しいことを日々の開発でどう検証すればよいか？」という、コンポーネント開発ならではの悩みも話題になりました。 第2回：グルーピングコンテンツ p 、 ul 、 ol 、 dl 、 figure 、 main など「毎日書いている要素」がテーマでしたが、担当の三上さんは意味の深い説明よりも、個人的に「そうなんだ」と感じた部分を中心にまとめてくれました。 たとえば、 p の中に ul を書くとエラーにはならず、パーサーが黙って p を閉じてしまいます。 <!-- 書いたつもりのHTML --> <p> <ul> <li>項目</li> </ul> </p> <!-- パース後のDOM --> <p></p> <ul> <li>項目</li> </ul> <p></p> その結果、 p > ul を前提にしたCSSが効かなくなったり、末尾に生える空の p で余白が増えたりします。SSR環境ではサーバーで生成したHTMLとクライアントのDOMが食い違い、hydrationエラーの原因にもなります。 ほかにも、次のような話題で盛り上がりました。 ol の番号はDOMに存在しないため、コピー＆ペーストすると消える main は hidden 属性を付けたものを含めれば、1ページに複数置ける hr は「線」ではなく、段落レベルのテーマの区切り。スクリーンリーダーでは「区切り」と読み上げられる dl の読み上げはブラウザとスクリーンリーダーの組み合わせによって差があるが、セマンティクスとして正しいなら使う価値がある この回で特に印象に残ったのが、「セマンティクス＝スクリーンリーダーのため」というチャットの発言に対する、辻さんのひと言です。 「スクリーンリーダーのため」ってのはたぶんちょっと違うな。スクリーンリーダーはHTMLの仕様に合わせて解釈する側なので。 スクリーンリーダーで思いどおりに読ませるためにコンテンツを曲げるのではなく、仕様に沿って正しくマークアップし、スクリーンリーダー側がそれを正しく解釈する。アクセシビリティを考えるうえでの順序を、改めて確認できました。 第3回：テキストレベルセマンティクス em と strong 、 small 、 s 、 time 、 ruby 、 bdi 、 br 、 wbr などを扱いました。 担当の齋藤さんからは「普段はフレームワーク上でコンポーネント単位でしかHTMLを書かないので、要素そのものを意識したことがなかった」という率直な感想があり、まさにこの輪読会の狙いどおりの気づきが共有されました。 書籍の刊行後に仕様側で変わった点も話題になりました。たとえば、書籍の時点では対応するARIAロールがなかった要素にも、WAI-ARIA 1.2ではロールが割り当てられています。 HTML要素 WAI-ARIA 1.2でのロール em emphasis strong strong del / ins deletion / insertion sub / sup subscript / superscript b / i / small / s / u generic ほかにも、 <p>H<sub>2</sub>O</p> をVoiceOverで読ませると「エイチ・ツー・オー」ではなく「エイチニオー」と読まれた、日本語にはイタリック体の文化がないので i 要素はマークアップと見た目が一致しにくい、といった実際に試してみたからこその話も出ました。 チャットでは、昔使っていたHTMLエディタの話や、ガラケーでHTMLを書いていた思い出話で世代を超えて盛り上がる一幕もありました。 第4回：フォーム その1 私の担当回です。 form 、 label 、各種 input の type 、バリデーション属性、 autocomplete などを扱いました。 特に強調したのは、 label の for 属性の落とし穴です。存在しない id を指定するとHTMLチェッカーでエラーとして検出できますが、 別の要素の id を指定してしまった場合はHTMLチェッカーでは検出できません。 ラベルをコピー＆ペーストして for を直し忘れると、コピーしたラベルまで最初の入力欄に紐づいてしまう、といった事故が起こり得ます。 これは目で見ても気づきにくい一方、スクリーンリーダーで読み上げるとすぐに分かる、という話が辻さんからありました。 そのほかにも、次のような話題が出ました。 type="hidden" は「秘密」にはならない（値は改ざんできる） pattern 属性はセキュリティのためのものではない placeholder はラベルの代わりにならない 電話番号を「ハイフンなし」と注釈して type="number" で受け取るのは避けたい KINTOのサービスには申込フォームが多いので、そのまま業務に生かせる内容だったと思います。 第5回：フォーム その2 最終回は溝口さんの担当で、 button 、 select 、 datalist 、 progress / meter 、 fieldset / legend などを扱いました。 溝口さんの切り口がとても面白く、「今はゼロからフォーム部品を手書きすることは少なく、UIライブラリを使うことがほとんど」という前提に立って、 MUI・Ant Design・Radix UIがそれぞれの要素をどう実装しているか を、書籍の内容と突き合わせてくれました。 たとえばスイッチ（Switch）コンポーネントひとつとっても、実装方針はライブラリごとに異なります。 ライブラリ Switchの実装 MUI 見た目用の span と、透明な <input type="checkbox" role="switch"> Ant Design input を使わず <button type="button" role="switch" aria-checked> Radix UI <button role="switch" aria-checked> に加え、フォーム内でのみ非表示の input を追加 select も同様で、ネイティブの select を使わずに role="combobox" と role="listbox" を組み合わせて再現していたり、フォーム互換のために見えない select を置いていたりと、各ライブラリの工夫が見えてきました。 「アクセシブルな複数選択UIを自前で実装するのはかなり大変なので、ライブラリを使うのがおすすめ」という結論にも説得力がありました。 また、スイッチは「押した瞬間に反映されるもの」なので、「保存」ボタンと組み合わせたり、月額／年額のような二択に使ったりするのは本来の用途とずれる、というSwitchとトグルボタンの使い分けの話も盛り上がりました。 ふりかえり 全5回を終えたあと、勉強会の1回分を使ってふりかえりを行いました。 フレームワークには、KPTではなく Fun / Done / Learn を採用しています。KPTだと特に問題がなくてもProblemを挙げる必要があり、ネガティブな空気になりやすいと考えたためです。 Fun：楽しかったこと 輪読会は負荷の高いフォーマットなのに、担当者が理解したことを積極的にシェアしてくれた ただ読んでくるだけでなく、担当者が独自の解釈を織り交ぜて、より高度な内容に仕上げてくれた（UIライブラリの対応状況など） 発表者ごとに本のどこに着目しているかが資料に表れていて、他の人がどう技術書を読んでいるのかを知ることができた 有識者のアクセシビリティの知見を踏まえて本を読み進める体験ができた 発表後のディスカッションで、全員が前のめりに建設的な意見を出す場になった 辻さんからは、こんなコメントももらいました。 昔のWeb制作者は、HTML解体新書に書いてあるくらいのことは普段使いしていた。今の時代は、そうした知識がなくてもプロダクトが作れてしまう。だからこそ、この輪読会を通してみなさんが知ろうとしてくれていることがうれしかった。 さらに、「世の中の登壇には、画面を見ていないと置いていかれるものが意外と多いけれど、今回のみなさんの発表は、画面を見ていなくても話として理解できた」という、うれしい言葉もいただきました。辻さんがこの点について書いた記事も紹介されていたので、発表をする方にはぜひ読んでほしいです。 https://note.com/debugon/n/nae7f164bf8a7 Done：やり遂げたこと フロントエンド勉強会で書籍を輪読するスタイルは初めてだったが、無事に完走できた 社内に『HTML解体新書』の存在を広められた 複数回にわたって1冊の技術書を読む、というスタイルを勉強会として1つ確立できた 一人で読むのがつらい本でも、勉強会に持ち込んでみんなで読む、という選択肢ができたのは大きな収穫です。 Learn：学んだこと HTMLの現行仕様は常に更新され続けるHTML Standardなので、書籍の内容はすでに古くなっている部分もある。だからこそ 書籍は取っかかりとして使い、怪しいと思ったら仕様を引く セクショニングコンテンツ、グルーピングコンテンツ、テキストレベルセマンティクスといったHTMLの原点を改めて思い出せた a 要素の内容モデルはTransparent（透過的）で、親がフローコンテンツなら a の中に div などを置くこともできる セマンティックなHTMLを書けばアクセシビリティを網羅できるわけではない。 結局、見出しやラベルを適切に付けることが、アクセシビリティ的に一番重要 見た目に頼っていたマークアップを、要素の意味から考え直すきっかけになった 担当になった人は誰も発表を避けず、1週間で1時間分の議論ができる資料を作ってきてくれた。 1回あたりの適切なボリューム感 もつかめた うまくいった理由をふりかえってみる ふりかえりの内容も踏まえて、今回の輪読会がうまくいった理由を整理すると、次の4つだと思います。 現場の課題から題材を選んだ 「なんとなく良さそうな本」ではなく、各チームへのヒアリングで見えた共通課題（情報設計・アクセシビリティ）から逆算して本を選びました。そのため、参加者にとって「自分ごと」になりやすかったのだと思います。 始めるハードルを徹底的に下げた 紹介する会を挟む、「読めなくても大丈夫」と明言する、範囲を主要な節に絞る、書籍を会社で用意する、といった工夫で、参加の心理的なハードルを下げました。 説明方法を担当者に任せた 本の内容をなぞるのではなく、「そうなんだ」と感じた点に絞る、UIライブラリと突き合わせる、など担当者ごとの切り口が生まれ、毎回違った面白さがありました。 有識者が一緒に読んでくれた 書籍の内容を、現在の仕様や実際のスクリーンリーダーの挙動と照らし合わせて補足してもらえたことで、「読むだけの会」から「理解して議論する会」になりました。 おわりに 今回の輪読会を通して、HTMLの知識そのものはもちろん、「勉強会で1冊の本を読み切る」という新しい型を手に入れることができました。 ふりかえりでは、次の題材としてReactの公式ドキュメントのような無料で読めるリファレンスを読むのも良さそう、という声や、書籍の内容を起点に、現在のHTMLの仕様やAI時代のマークアップについてさらに議論を深める場をつくれないか、というアイデアも出ています。 少人数のふりかえりではありましたが、この輪読会を乗り越えたことで、新しいことができそうな可能性を感じています。 社内で輪読会を企画しようとしている方の参考になればうれしいです。

はじめに こんにちは！株式会社エブリーで1ヶ月間、iOS エンジニアとしてインターンをしていた木村風葉です。ヘルシカの iOS チームで、食事記録まわりの改善や無料会員向けの機能追加など、いくつかの機能開発に取り組みました。 この記事では、インターンの後半に取り組んだ「 Jev 」という新しいAIを使った検証ツールづくりについて書きます。Jevは、文章を生成する代わりに「選択肢のどれを選ぶか」を確率付きで返すAIです。これを使ってiOSシミュレータ上のアプリを自動で触り回らせ、不具合を探す仕組みを作りました。 なお、ヘルシカの開発チームでは、AI コーディングツールの Claude Code を日常的に使っています。この記事で Jev と比べている「Claude」は、基本的にこの Claude Code を指します。 はじめに Jev とは 作ったもの：jev-qa きっかけ 構成 1ステップの流れ Jev の判断をそのまま使わない 探索モード：ゴールを決めずに触り回る 気になる点を「スクショの名前」で記録する 「123456 の次は 123457」を試せる探索 比較と評価 「Claude がやったほうが早くない？」問題 料金 Claude と Jev の使い分け 見つかったもの 課題 失敗談：課金画面の購入ボタンを押しかけた 「わかりにくい表示」の判定が当てにならない まとめ 参考資料 Jev とは Jev は、TypeSafe AI が開発した「System One Model」と呼ばれる AI モデルです。ChatGPT や Claude のような LLM（大規模言語モデル）は文章を生成しますが、Jev は文章を生成しません。 状態（state）と、型の決まった質問（questions）を渡すと、それぞれの質問に対する答えを確率付きで返します。 docs.typesafe.ai 質問の型は次の3つです。 型 返ってくるもの 例 noul 真である確率（0〜1） 「エラーが表示されているか」→ 0.93 choice 選んだ選択肢と、全選択肢の確率 「次に押すボタンはどれか」→ 「続行(3/4)」 score 段階評価と、各段階の確率 「健康的な度合い（悪い／普通／良い）」 たとえば、1日の食事内容を渡して「栄養バランスが取れているか」「一番の課題は何か」を聞くと、次のような形で答えが返ってきます（イメージです）。 { " answers ": { " is_balanced ": { " noul ": 0.12 } , " main_issue ": { " choice ": " veg ", " confidence ": 0.81 , " probabilities ": { " carb ": 0.11 , " fat ": 0.08 , " veg ": 0.81 } } } } 主な特徴は次のとおりです。 速い : 1回の判断が数百ミリ秒程度で返ってきます 安い : 入力は 100万トークンあたり $0.042 で、出力は無料です（2026年10月時点） 入力はテキストだけ : 画像は渡せません 今回は、社内で検証用に一時的に用意していただいた環境を使って試しました。 作ったもの：jev-qa きっかけ 検証用の環境を用意していただいて最初に思いついたのは、 アプリの動作確認 です。オンボーディング（初回の登録の流れ）を毎回手で進めるのが大変だったので、「Jev に画面を判断させながら、高速に操作させられないか」と考えました。 ただ、オンボーディングは画面の順番が決まっています。決まった手順を毎回 AI に判断させるより、手順を書いたテストスクリプト（XCUITest など）のほうが速くて確実です。そこで、目的を次のように広げました。 オンボーディングをjevで通せるなら、その先の画面も触らせて、不具合探しにも使えるのでは？ 手順が決まっていない状態でアプリ中を触り回るのであれば、毎回その場で判断が必要になります。ここなら、速くて安い Jev の出番があるのではないかと考えました。 構成 作ったツールは jev-qa と名付けました。(今思えばヘルシカに限定した名前の方が良かったかも...) 主な構成は次のとおりです。 AXe : iOS シミュレータの画面情報を読み取り、タップや入力を行う CLI ツール jev_qa.py : 画面の情報を Jev に渡し、返ってきた判断をもとに操作する Python スクリプト 設定ファイル（YAML） : アプリ固有のルールや、検証したい操作の流れ（シナリオ） github.com 1ステップの流れ Jev には画像を渡せないので、スクリーンショットではなく アクセシビリティの情報 （画面上のボタンや文字の情報をテキストにしたもの）を渡します。1ステップの流れは次のとおりです。 1ステップの流れ Jev には、1回の呼び出しで次の質問をまとめて聞いています。 質問 型 答え operation choice タップ／入力／下にスクロール／上にスクロール／戻る／待つ／完了／行き詰まり target choice 操作する要素の番号 is_error_shown noul エラー表示が出ているか goal_achieved noul ゴールを達成したか ここでハマったのが、 Jev は質問ごとに別々に判断していて、ほかの質問の選択肢を見ていない という点です。最初は要素の一覧を target の選択肢にだけ入れていたため、 operation を判断するときに画面の中身が分かっていませんでした。そのため、要素の一覧は状態（state）にも入れるようにしました。 Jev の判断をそのまま使わない 動かしているうちに、Jev の判断をそのまま使うと困る場面がいくつも出てきました。たとえば、 同じボタンを押し続ける、自信が無いのに「戻る」を選ぶ 、といった動きです。そこで、ツール側で次のような補正をかけるようにしました。 自信度が 0.7 未満の「戻る」は実行しない 画面が変わらなかったのに同じ要素を押そうとしたら、次に確率が高い要素にする 購入・削除・退会・サインインなどのボタンは押さない 課金画面（paywall）が出たら、Jev に判断させずに左上の × を押す また、Jev が「ゴールを達成した」と答えても、それだけでは完了にしないようにしました。自己申告だけで完了にすると、失敗しているのに完了扱いになることが連発したためです。代わりに、シナリオの段階ごとに「この画面にこの文字が出ていたら達成」という条件（ done_when ）を書き、ツールが確認します。 シナリオの例(イメージ) name : 体重を記録する start : relaunch : true # アプリを再起動してから始める screen : home inputs : [ "60.5" ] # 入力欄に入れてよい値 stages : - goal : 体重の記録画面を開く done_when : screen : weight_record max_steps : 6 - goal : 体重を 60.5 kg で保存する done_when : texts_all : [ "60.5" ] screen : home max_steps : 8 ゴールを段階に分けたのは、Jev が「この画面で次に何を押すか」を選ぶのは得意な一方、長い手順の中で「今どこにいて、何をすべきか」を判断するのは苦手だったためです。判断させる範囲を小さくするほど、動きが安定しました。 こうして、体重の記録、運動の記録、設定画面の行き来、日付の切り替えなど、いくつかのシナリオを通せるようになりました。 jev-qa が運動記録にウォーキング30分を追加している様子 探索モード：ゴールを決めずに触り回る 決まったフローの確認よりも Jev が活きそうなのが、 ゴールを決めずにアプリ中を触り回る探索 です。秒数を指定すると、まだ押していないボタンを優先して押し続けるモードを作りました。 python3 jev_qa.py --explore 240 # 240秒、ゴールを決めずにアプリ中を触る 固まった、アプリの外に出た、完全に行き詰まった、といった場合は、アプリを再起動して続けます。最初の4分間の探索では、83ステップで65種類のボタンを触りました。 気になる点を「スクショの名前」で記録する 探索の目的の1つは、不具合や、ユーザーにとってわかりにくい表示を見つけることです。ただ、Jev は文章を出せないので、「何がおかしいか」を説明させることはできません。そこで、 気になる点があったら、スクリーンショットを ISSUE_<種類>_step<番号>.png という名前で残す ことにしました。何かあったことさえ分かれば、あとから人や Claude が見て判断できます。 種類 判定する方法 エラー表示・ わかりにくい表示 Jev（ noul の確率が高いとき） ボタンの読み上げ名が画像のファイル名になっている、仮の値（ null など）が出ている スクリプト 固まった・アプリの外に出た・行き詰まった ツール ここでいう 「わかりにくい表示」 は、Jev に「画面に、ユーザーにとってわかりにくい・不自然な表示があるか」を noul で聞き、その確率が高かったときに記録するものです。質問文には、説明のない数値や記号、意味の通じない文言、不自然な空欄などを例として書いています。 「123456 の次は 123457」を試せる探索 探索を何回かに分けて流すと、毎回同じところばかり触ってしまいます。そこで、画面と操作の記録を、実行をまたいで残すようにしました。 最初は「一度押したボタンは次から避ける」という単純な仕組みにしました。しかし、それでは不十分でした。たとえば、ボタン 1→2→3→4→5→6 と進んだ後、6 の代わりに 7 を押すルート（1→2→3→4→5→7）も試してほしいのに、1 が「押した」扱いになると、その先の分岐を試せなくなります。 そこで、画面と遷移をグラフ（画面A --[押したボタン]--> 画面B）として記録し、次のルールで選ぶようにしました。 分岐を残したまま「済み」にしない探索 その画面に、まだ押していないボタンがあれば、それを押す 全部押し済みなら、 押した先に未探索の分岐が一番近く残っているボタン をもう一度押す 先が全部探索済みなら、戻るかスクロールする 途中のボタンは、その先がすべて探索済みになるまで「済み」にしません。これで、1→2→3→4→5→6 を試した後に、1〜5 を通り直して 7 を試す動きになりました。 比較と評価 「Claude がやったほうが早くない？」問題 シナリオが通るようになってきた一方で、運動の記録（ウォーキング30分を追加する）シナリオを動かしたとき、 1回に47秒 かかりました。オンボーディングのときより、1つ1つの操作が明らかに遅く感じました。 試しに、Jev を使わずに Claude に同じシナリオの操作をさせてみたところ、 19.5秒 で終わりました。正直、「 これなら Jev を使う意味なくない？ 」と思いました。 まず、どこに時間がかかっているのかを測りました。 Jev の判断 操作 画面の変化待ち 1ステップの平均 0.33秒 1.16秒 2.01秒 Jev の判断は1ステップあたり0.3秒ほどで、全体の1割程度でした。時間の大半は、画面の読み取りと操作、 つまり Jev 以外の部分でかかっていました。 原因を調べると、AXe がタップのたびに画面の向きを確認していて約0.6秒かかることや、画面の読み取りが要素の数に比例して遅くなることが分かりました。入力の手順を整理したり、操作後の固定の待ち時間をやめて画面の変化を見て進むようにしたりして、運動の記録のシナリオは 47.1秒 → 約33秒 になりました。 また、Claude の19.5秒は、何度も動かして画面の流れやボタンの名前を把握したうえで、 あらかじめ完璧な手順を書いたスクリプト を実行した時間でした。初めて見る画面で同じことはできません。Claude が1手ずつ画面を見て判断する場合は、1手ごとに数秒以上かかり、費用も Jev より桁違いに高額になります。 整理すると、次のようになります。 やり方 速さ 初めて見る画面 画面が変わったとき 費用 決め打ちのスクリプト ◎ × 事前に作る必要がある × 壊れる ほぼ0 Jev が1手ずつ判断 ○ ○ ○ ほぼ0 Claude が1手ずつ判断 △ ◎ ◎ 高い ここから、 決まった操作フローの確認なら決め打ちのスクリプトのほうがよく、Jev は手順が決まっていない「探索」に向いている 、という方向性が見えてきました。 料金 Jev は入力が安く、出力が無料なので、料金はほとんどかかりませんでした（1ドル150円で計算）。 実行 入力トークン 料金 1ステップ 約1,500 約0.01円 シナリオ1本（4〜9ステップ） 7,500〜17,000 約0.05〜0.1円 探索 4分 12.5万〜14.5万 約0.8〜0.9円 4分間アプリを触り回って1円以内 です。シナリオ6本を1日10回流しても、月に200円もかかりません。(もちろん1日10回回す必要はないですが...) Claude と Jev の使い分け 最後に、Jev を使わずに Claude だけで2分間の探索をさせ、Jev と比べてみました。 Claude が直接操作 Jev による探索 1操作あたり 約7秒 約2〜3秒 2分で触れた数 15操作 40〜50操作 料金 Claude の利用量 約0.5円 見つけやすいもの 意味を伴う違和感（表示の順番、仕様と合っているか など） エラー表示、固まる、行き詰まる この結果から、次のような使い分けがよいと考えています。 決まった操作フローの確認 : 決め打ちのスクリプト（速くて確実） 広く速く触って、異常を見つける : Jev（速くて安い） 見つかったものの意味を判断する、原因を調べる、シナリオを書く : Claude Jev は Claude の代わりになるものではなく、 大量に、速く、安く判断したい部分を受け持つ部品 だと感じました。 見つかったもの 数日間の試行で、手で触っていたときには気づいていなかった不具合や、仕様を確認したほうがよさそうな点がいくつか見つかりました。 見つかったものは、大きく次の3種類でした。 動作の不具合 : アプリが応答しなくなる、エラーが表示されるといった、ユーザーの操作が止まってしまうもの 表示の違和感 : 画面の状況と文言が合っていないなど、仕様として意図どおりかを確認したいもの アクセシビリティの問題 : 画面の読み上げで、ボタンの役割が伝わりにくいもの 特に役に立ったのは、普段あまり通らない操作の組み合わせで起きるものを拾えたことです。探索モードは人が普段やらないようなパターンも網羅的に走査できるので、手での確認では通りにくい道筋を自然に通ってくれました。見つけたときにはスクリーンショットと操作の記録が残っているので、再現手順をすぐに確認でき、そのまま原因の調査につなげられました。 アクセシビリティの問題は、最初から探していたわけではなく、ツールを作っている途中で気づいたものです。このツールは画面を読むのにアクセシビリティの情報を使っていて、これは iPhone の読み上げ機能（VoiceOver）が読み上げる情報と同じです。つまり、ツールで読んだボタンの名前が画像のファイル名になっていれば、VoiceOver でもそのまま読み上げられているということです。ボタンに意味のある名前が付いていれば、Jev や XCUITest もボタンを見分けやすくなるので、テストのしやすさにもつながると感じました。 課題 失敗談：課金画面の購入ボタンを押しかけた 探索モードでは、ヒヤッとすることもありました。 探索中に課金画面（paywall）が開いたのですが、Webで表示される画面だったため中身の読み込みがツールの確認より遅れ、ツールが課金画面に気づけませんでした。ツールは後ろにあるホーム画面の情報をもとにボタンを押すため、その位置によっては課金画面の購入ボタンを押す可能性があります。 シミュレータはAppleアカウントにサインインしていなかったので実際に有料プランの購入を完了させることはありませんが、AIに操作させるときは「押してはいけないものを押す」前提で守りを固める必要がある、と実感しました。対策として、次の3つを入れました。 押す直前に、押す位置の要素が今の画面の情報に含まれているかを確かめる。含まれていなければ押さない サインイン画面が出たら、Jev に判断させず「キャンセル」だけを押す 探索モードでは、課金画面の入口になるボタンを押さない 「わかりにくい表示」の判定が当てにならない Jev による「わかりにくい表示」の判定は誤検知が多く、正直なところあまり役に立ちませんでした。一方で、エラー表示の判定や、スクリプトでの判定は役に立ちました。表示の意味まで踏み込んだ判断は、今のところ Claude や人が見たほうが確実です。ツールの実行をClaudeに持たせればツールの検知した「わかりにくい表示」が誤検知かどうかQA後に判定してくれるので、そのような実行方法の方が振り返りやすいと思います。 まとめ Jev を使って、iOS シミュレータ上のアプリを自動で触り回る検証ツールを作りました。 取り組みを通じて、次のことを学びました。 AI に操作させるときの速さは、AI の判断以外で決まることが多い 。推測せずに測ったら、Jev の判断は全体の1割程度でした AI に判断させる範囲は小さくする 。長いゴールを段階に分けると、動きが安定しました AI の自己申告をそのまま信じない 。完了の判定や、押してはいけないボタンは、ツール側のルールで決めます 道具ごとに得意なことが違う 。決め打ちのスクリプト・Jev・Claude を役割で使い分けるのがよいと考えています 今後は、Jev がアプリを操作し、失敗したときは Claude が原因を調べて設定を直す、という仕組みも作ってみたいです。その際は、テストを通すために Claude が合格の条件を緩めてしまわないよう、Claude に直させてよい範囲を決めておく必要があります。 エブリーのインターンでは、複数の機能開発だけでなく、新しい技術を試して開発のやり方そのものを改善する取り組みにも挑戦できました。実際にチームに入り、新機能の実装からリリースまでの一連の流れに関われたのは、とても貴重な機会でした。 社員の皆さんは明るく接しやすい方ばかりで、気軽にランチにも誘っていただきました。おかげで、楽しく充実した1ヶ月を過ごせました。大変お世話になりました。 新しい技術を試しながらプロダクトの開発に関わりたい方は、ぜひエブリーのインターンに応募してみてください！ ※28卒インターンの募集は終了しました 参考資料 docs.typesafe.ai thenewstack.io github.com