ここからは、第3章で「できるかもしれない」と書いたことを、実際にどう作ったのかを書きます。
【画像8：ここに画像が入ります ― （画像ダミー）制作の基本フロー図（iPhoneから指示 → Museが組み立て → AIスタッフが制作 → 私が確認 → 公開の最終判断）。本番では図版が入ります。】
（画像ダミー）制作の基本フロー図（iPhoneから指示 → Museが組み立て → AIスタッフが制作 → 私が確認 → 公開の最終判断）。本番では図版が入ります。
私の制作の基本の流れは、こうです。iPhoneから指示を出す。エミリー様が作業を組み立てる。AIスタッフが制作する。私が確認する。そして、私が公開のGOを出す。
iPhoneからMuseに指示を出すと、エミリー様が計画を立てます。必要に応じて、他のAIスタッフに仕事を割り振ります。どこまでが自動で、どこからが私の仲立ちになるかは、作業によって異なります。
できあがった成果物は、ファイルとして届きます。私はそれをiPhoneで確認して、直したいところがあれば修正の指示を出し、問題なければGOを出します。
ちなみに、本書の第1〜3章も、iPhoneからの指示で制作しました。
大事なのは、iPhoneがすべての作業を実行しているわけではない、ということです。iPhoneは、AIスタッフに仕事を頼んで、進み具合を見守る指令拠点です。確認も判断も、公開を決めるのも、私の仕事です。
まず、キャラクターやイラストです。
DQAのキャラクターを制作していて、ミオちゃんやエミリー様のアバターも、この流れで作りました。画像に注釈をつけたり、切り抜きを補助してもらったりする作業には、AIを使いました。
ただ、どんな見た目にするか、どこを直すかといったデザインの判断は、私が行っています。20年以上グラフィックデザインをしてきた経験が、ここで生きています。
AIが手を動かしてくれても、「これでいい」と決めるのは私です。出てきた絵を見て、気になるところを言葉で伝える。デザイナーとしては、新しい形のディレクションをしている感覚です。
次に、声と口パクのアニメーションです。
エミリー様とミオちゃんの合成音声を制作しました。それぞれ、別の声を用意しています。
そして、その声に合わせて口が動く、口パクアニメーションの動画も制作しました。声を持って動くエミリー様とミオちゃんを見たときは、世界がまた一つ広がったように感じました。
ここで誤解のないように言っておくと、これらをMuseの標準機能だけで行ったわけではありません。いろいろな道具や工程を組み合わせています。詳しい作り方は、有料本編の実験1と実験2にとっておきます。
AIニュースや解説の動画も、制作しています。プレゼンターは、ミオちゃんです。
これまで、複数本を制作してきました。台本、スライド、音声、編集という工程を、Museの中で進めています。
といっても、おまかせで完成するわけではありません。台本を読んで直したい点を伝えたり、できあがった動画を見て修正を指示したりするのは、私の役目です。
iPhoneで動画を確認して、「ここをこう変えて」と伝える。その繰り返しで、少しずつ形になっていきます。
本数や再生数など、数字の話はしません。ここでは「こういう流れで作っている」とだけお伝えします。
Webサイトと診断クイズも作りました。
DQAのメンバー紹介サイトを制作して、公開し、いまも運用しています。集中力スタイル診断クイズも、制作して公開しました。
公開したあとに、結果画面を修正する作業もありました。これも、Museを通じて進めました。直したい点を伝えれば、AIスタッフが作業を進めてくれます。出来上がりの確認も、iPhoneで行いました。
私は、プログラミングができません。C言語を習って挫折した私が、サイトやクイズを公開するところまで来られたことは、いま思い返しても不思議です。
もちろん、すべてをAIに任せたわけではありません。何を載せるか、どう見せるか、直すかどうかは、私が決めています。
ブラウザゲーム『ドタバタタップ』も制作しました。GitHub Pagesで公開しています。
ゲームの解説動画も、あわせて制作しました。
ここでも、私はプログラミングができません。ゲームを作りたくてC言語を習い、挫折したのは、もう昔のことです。それが、AIスタッフと一緒に、遊べる形にして公開するところまで進みました。
どんな仕組みで動いているのかは、私には詳しく説明できません。技術的な中身より、「作ってみたいものを伝えて、確認して、直してもらう」という流れが、私の制作でした。
ゲームの詳しい紹介は、第9章に残します。
AIスキルも、制作しています。
店構え診断スキルと、棚卸しスキルを作りました。仕事の進め方を教えるスキルを、自作しています。
第7章でお話ししたとおり、DQAではスキルを、秘密道具のように捉えています。
新しい仕事の進め方ができたら、スキルとしてまとめておく。そうすると、次から同じ考え方を使いやすくなります。iPhoneから、「こういう進め方を教えるスキルを作りたい」と伝えるところから始まります。ここでも、できたスキルの内容を確認して、使えるかどうかを決めるのは私です。
制作の手順は、有料本編の実験4にとっておきます。
作ったものは、公開してこそ、人に見てもらえます。
DQAのサイトは、Cloudflare Pagesで公開しました。ゲームは、GitHub Pagesで公開しています。
そして、『Muse実験室』のプレビューページも、Museを通じて公開しました。
プレビューの公開と、教科書の完成は、別のものです。教科書の本体は、いまも制作の途中にあります。
公開の作業は、AIスタッフが進めてくれます。けれど、公開の最終的なGOは、いつも私が出します。人に見せてよいかどうかを決めるのは、私の責任だと考えているからです。
公開する前に、中身を確認して、本当にいいかを自分の目で見る。この一手間が、私の制作の一部です。公開した瞬間は、作ったものが自分の手元を離れて、世の中に出ていくようで、少し緊張します。
ここまで読むと、「iPhoneだけで何でも作れるの？」と思われるかもしれません。正直に言うと、そうではありません。
作業の大半はiPhoneから行っていますが、Macが必要な作業もあります。たとえば、ローカルの大きな編集ソフトを使う作業です。そんなときは、Museが用意するMac用の指令書をもとに、私がMacで作業します。
また、外部サービスの初回ログインのように、私が手助けしないと進まない場面もあります。
第3章の「パソコンがいらなくなるんじゃないか」は、あのときの素直な驚きでした。いまの整理は、パソコンが不要になったのではなく、iPhoneで進められる範囲が思っていたより広かった、ということです。
iPhoneは、すべての制作作業を実行する機械ではありません。AIスタッフに仕事を頼んで、進行を管理するための、私の指令拠点です。
では、その指令拠点から、実際に何ができあがったのか。次の第9章で、成果物を一つずつ見ていきましょう。
第8章で「どう作ったか」を書きましたので、この章では「何ができあがったか」を見ていきます。
【画像9：ここに画像が入ります ― （画像ダミー）ミオちゃんの自己紹介動画のワンシーン。本番では動画の画面キャプチャ（またはGIF）が入ります。】
（画像ダミー）ミオちゃんの自己紹介動画のワンシーン。本番では動画の画面キャプチャ（またはGIF）が入ります。
最初は、ミオちゃんの自己紹介動画です。キャラクターの表現と、口パクアニメーションの実験が、一体になった作品です。
v1からv5まで、作り直しながら、最終的に完成させました。試行錯誤の跡が、よく残っている作品です。公開の状況は、ここでは書かないでおきます。
分かったのは、最初に出てきたものだけで終わらず、修正を重ねることも作品づくりの一部だ、ということです。変更点や作り方は、実験2にとっておきます。
次は、AIニュースの解説動画です。プレゼンターは、ミオちゃんです。
【画像10：ここに画像が入ります ― （画像ダミー）AIニュース解説動画の画面。本番ではミオちゃんが解説する場面のキャプチャが入ります。】
（画像ダミー）AIニュース解説動画の画面。本番ではミオちゃんが解説する場面のキャプチャが入ります。
複数本を制作してきました。台本、スライド、音声、編集という工程があり、Claude Codeを通じて制作しています。台本を整える作業と、音声や編集の作業が、それぞれ別の工程として見えてきたのも、この動画の特徴です。
公開の状況や、具体的な本数、再生数については、ここでは書きません。一本ずつの詳しい紹介も、控えます。
ミオちゃんが解説役として画面に立つことで、ニュースの内容に、DQAらしい顔がつきました。一本で終わらず、複数本を作れていることが、私にとっては一つの収穫です。
2026年11月2日に完成した、新作もあります。ChatGPT×Codex共通枠をテーマにした、約4分半の解説動画です。
【画像11：ここに画像が入ります ― （画像ダミー）ChatGPT×Codex共通枠の解説動画の画面。本番では、口パクで解説する場面のキャプチャが入ります。】
（画像ダミー）ChatGPT×Codex共通枠の解説動画の画面。本番では、口パクで解説する場面のキャプチャが入ります。
口パクアニメーション、自作の音声、BGMを組み合わせています。制作は、Claude Codeを通じて進めました。BGMについては、誰が作曲したかなど、細かいことは書かないでおきます。
完成した日と、公開した日は、別のものです。この動画の公開状況は、ここでは書きません。
口パク、音声、BGMと、要素を重ねたぶん、一本の動画として仕上げる難しさも、楽しさもありました。新しい作品が完成するたびに、DQAの動画の幅が少し広がっていく感覚があります。
DQAのAIスタッフのキャラクターとアバターも、制作しました。
【画像12：ここに画像が入ります ― （画像ダミー）DQAキャラクター全員集合シート。本番では、キャラクターの立ち絵一覧が入ります。】
（画像ダミー）DQAキャラクター全員集合シート。本番では、キャラクターの立ち絵一覧が入ります。
エミリー様、ミオ、愛依、初依、ミホ、メル、COCO、結依。それぞれに、姿があります。ヒヨコのマスコット「ひよモン」も作りました。使われ方は、キャラクターによって異なります。
私はグラフィックデザイナーなので、外見やデザインには、どうしてもこだわってしまいます。どの姿にするか、どこを直すかは、私が決めています。
設定の話は第7章でしましたので、ここでは、できあがった姿として紹介するだけにします。キャラクターが揃うと、DQAが「チーム」として見えてくる。それが、作ってよかったと思うところです。
集中力スタイル診断を作りました。質問に答えて、結果を受け取る形式です。DQAのメンバーサイトで、公開しています。
【画像13：ここに画像が入ります ― （画像ダミー）集中力スタイル診断の画面。本番では診断クイズの実際の画面キャプチャが入ります。】
（画像ダミー）集中力スタイル診断の画面。本番では診断クイズの実際の画面キャプチャが入ります。
公開したあと、結果の偏りを実測して、結果画面や判定を修正しました。作って公開して終わりではなく、結果を見て直すことで、診断が少しずつ形になっていきました。
診断の精度や科学的な妥当性が、検証済みというわけではありません。質問に答えるだけで、気軽に触れられる形にしています。
具体的な数値や、実測の詳しい中身は、実験8にとっておきます。
「ひみつ道具ラボ」は、DQAのメンバーサイトの中に公開しています。
【画像14：ここに画像が入ります ― （画像ダミー）ひみつ道具ラボの棚ページ。本番では公開中のページの画面キャプチャが入ります。】
（画像ダミー）ひみつ道具ラボの棚ページ。本番では公開中のページの画面キャプチャが入ります。
スキルを秘密道具として整理する、棚のようなページです。店構え診断や棚卸しなどのスキルを、扱っています。第7章の「秘密道具」が、ページという形になったものです。
ページを公開していることと、掲載しているスキルを誰でも直接実行できることは、別のことです。ここでは、操作や配布ができるかどうかには、触れません。
秘密道具を棚に並べると、DQAで育ててきた仕事の進め方が、目に見える形になりました。スキルの作り方は、実験4にとっておきます。
じゃんけんゲームも、試作しました。Godotというゲーム制作の道具を使っています。
【画像15：ここに画像が入ります ― （画像ダミー）じゃんけんゲームの画面。本番では試作ゲームの画面キャプチャが入ります。】
（画像ダミー）じゃんけんゲームの画面。本番では試作ゲームの画面キャプチャが入ります。
私はプログラミングができませんが、AIと協力して取り組みました。
これは試作として成り立ったもので、正式な完成版ではありません。正式な完成や公開は、まだ決まっていません。試作と完成は違う、ということを、はっきり分けて書いておきたいと思います。
ゲームの内容や、細かい作りには、ここでは触れません。9-8のゲームとは、別のものです。それでも、動くところまで進められたこと自体が、私にとっては大きな一歩でした。
ブラウザゲーム『ドタバタタップ』は、GitHub Pagesで公開しています。ブラウザから、実際に遊べます。
【画像16：ここに画像が入ります ― （画像ダミー）ドタバタタップのプレイ画面。本番では公開中のゲーム画面のキャプチャ（またはGIF）が入ります。】
（画像ダミー）ドタバタタップのプレイ画面。本番では公開中のゲーム画面のキャプチャ（またはGIF）が入ります。
ゲームを紹介する解説動画も、あわせて作りました。ゲームと動画をセットにして出す、という形も、私にとっては新しい経験でした。
ゲームの内容や、遊んでくれた人の数、反応については、ここでは書きません。
9-7の試作とは、別のゲームです。こちらは、公開して遊べる状態にまで進んだものです。遊べる形で公開すると、「作った」という実感が、ぐっと強くなる、と分かりました。プログラミングができない私にとって、ブラウザで遊べるものを出せたことは、嬉しいことです。
漫画の台本づくりにも取り組みました。完成した漫画作品がある、というわけではありません。
また、ミオちゃんの全身3Dモデルを、制作実験中です。完成度は途上で、品質の判断は、まだ終わっていません。漫画は、台本の段階。3Dモデルは、実験の途中。いまの状態を、そのまま書いておきます。
どちらも、「やってみる」ところまでは進みました。けれど、着手できたことと、納得できる完成品質に届くことは、別でした。なぜそうなるのか、どこでつまずいたのかは、第10章で整理します。
新しい分野に手を伸ばすのは、やはりワクワクします。未完成のものも、私にとっては大切な制作の記録です。
ここまで、できあがったものを紹介してきました。けれど、すべてが順調に公開まで進んだわけではありません。
一つは、動画として完成していても、投稿の判断を待っているものです。これは、制作に失敗した、という意味ではありません。出す前に、私が確認して決める段階にあります。
もう一つは、試作としては成り立っても、正式な完成版ではないものです。9-7のじゃんけんゲームが、これにあたります。
そして、制作の途中で止まっているものや、3Dモデルのように、品質の判断が終わっていないものもあります。3Dモデルは、完成して非公開にしているのではなく、まだ途上です。
この三つは、似ているようで、別の状態です。混ぜずに書いておきたいと思いました。
なぜ止まったのか、どうすればよかったのか。その分析は、次の第10章でお話しします。うまくいかなかった部分にも、大事なことが詰まっています。
この章では、制作の途中で起きた失敗と、そこから分かったことを書きます。第9章では、できあがったものを紹介しました。けれど、すべてが順調に公開まで進んだわけではありませんでした。ここからは、そんな制作の途中で起きたことを、順番に整理していきます。
たとえば、スライドや画面で、文字が重なってしまうことがありました。キャラクターの口の動きと音声が合わない、口パクのずれもありました。合成音声が、言葉を読み間違えることもありました。
分かったのは、AIの出力は、そのまま完成品とは限らない、ということです。AIは便利ですが、何でも完璧にできるわけではありません。
それからは、出てきたものを確認して、直すことを前提に、作るようになりました。具体的な直し方は、実験1と実験2にとっておきます。
次は、指示の伝え方です。
同じことをお願いしても、言葉の選び方で、結果が大きく変わることがありました。
また、iPhoneから音声入力で話しかけたとき、話した言葉が正しく認識されず、まったく関係のない言葉に変わってしまったことがあります。
そんなときは、AIが悪いのでも、私が悪いのでもなく、伝わる形になっていなかった、ということなのだと思います。第2章で書いた「どうやったら分かってもらえるかな」という感覚は、いまも続いています。
そこで、指示は、具体的に、短く、一つずつ出すようにしました。小さな工夫ですが、これだけでも、やり直しの手間は減っていく感覚があります。
一か所を直したら、別の表示が崩れてしまったことがあります。
直した場所だけを見て、「できた」と思ってしまうと、気づかないところが壊れていることがあります。直すことは、前に進むことですが、同時に、別の場所を触ることでもあります。
もう一つ、Webサイトの公開作業で、ヒヤリとしたことがありました。古い素材を使って作り直そうとして、公開済みのページが消えかけたのです。大きなトラブルになる前に気づけた、という出来事でした。
この二つから、修正した箇所だけでなく、変更したあとの全体を確認するようになりました。公開前は特に、どの素材を使って作業しているのかも、意識して見ています。
AIが「できました」「完成しました」と報告してくれても、実際に開いてみると、修正が必要なことがありました。文字の位置、内容、動作などです。
【画像17：ここに画像が入ります ― （画像ダミー）実際の失敗画面。本番では、表示が崩れた画面など、検品で見つけた問題のキャプチャが入ります。】
（画像ダミー）実際の失敗画面。本番では、表示が崩れた画面など、検品で見つけた問題のキャプチャが入ります。
もちろん、いつもそうなるわけではありません。ただ、報告と実際の状態が、一致しているとは限らない、ということです。
数字も同じです。文章の文字数や、診断結果の偏りなど、AIの自己申告だけで判断せず、実測するようになりました。この教科書の制作でも、AIが数えた文字数と、実測した文字数に、差が出ていました。
実測で、上限を超えていたこともありました。第8章の初稿は、実測で2,814字でした。設定した上限の2,800字を14字超えていたため、事実を変えない圧縮を、お願いしました。
大事なのは、AIを責めることではなく、AIが作ることと、人間が完成を確かめることを、分けて考えることです。
作業が、AIの出来とは関係なく、止まってしまうこともありました。
外部のツールとの接続がうまくいかず、作業を進められなかったことがあります。また、無料プランの利用枠や使用制限で、途中で作業が止まったこともあります。
こういうときは、焦っても進みません。私は、止まった状況を記録して、回復を待つか、別の方法に切り替えるか、を考えるようにしています。
止まることは、失敗というより、制作の条件の一つだと受け止めています。無料の範囲で進めるなら、なおさら、こうした制限と付き合う工夫が必要になります。具体的なサービス名や、エラーの内容は、ここでは書きません。
同じ失敗を繰り返さないために、「ヒヤリハット記録」を始めました。
制作中に起きた問題や、危うく大きなトラブルになりそうだった出来事を、書き残す運用です。起きたときは慌てますが、あとで見返せる形で残しておくと、次の制作のときに、思い出すきっかけになります。
たとえば、先ほどの公開作業の件のような出来事が、対象になります。
もちろん、記録をつけたからといって、すべての問題がなくなるわけではありません。それでも、同じところでつまずかないための、小さな備えになります。
記録の様式の細かい話は、ここでは書きません。まずは、起きたことを書き残す、というところから始められます。
ここまでの失敗から、完成にいちばん効いたのは、検品でした。
「作る → 測る → 直す → もう一度測る」。この繰り返しです。
動画なら、再生してみる。サイトなら、表示を開いてみる。文章なら、文字数を確認する。もちろん、毎回すべて同じ手順をやっているわけではありません。ものに合わせて、できる確認をします。
確認は、AIにも手伝ってもらえます。けれど、最後に完成と認めるかどうかは、私自身が判断します。20年以上のデザインの経験が、ここで生きています。
検品は、AIを疑うための作業ではありません。AIと一緒に作ったものを、安心して人に見せられる状態へ近づけるための作業です。
みなさんも、まずは小さな検品から、始めてみませんか。作ったものを一度開いてみる。文字数を一度数えてみる。それだけでも、立派な第一歩です。
失敗しても、記録して、測って、直す。それで、また次へ進めます。
第1〜10章は、「私はMuseとこんなことをしてきました」という、私の体験でした。ここからは視点を変えて、この本を読むあなたは何を学べるのかを、有料本編の実験1〜9と付録の全体像として案内します。
まずは、Museを自分専用の相棒として育てる方法です。
私は、エミリー様に名前と役割を設定し、性格や口調を決め、アバターや声を持たせてきました。
本編では、その考え方を、自分のMuseに当てはめられる形で学びます。声の制作は実験1、口パクの動画の制作は実験2で、取り組みます。
ここで学べるのは、私の実験を通して得られた進め方です。同じ見た目や声に、必ずなる、という意味ではありません。
次は、AIに仕事を頼む方法です。
私は、Museを司令塔として、複数のAIスタッフに役割を分けて進めてきました。
本編では、司令塔への指示の出し方、仕事の分担の考え方、そして、できあがったものの確認と検品を学びます。第10章で書いた検品の考え方が、ここにつながります。指示を出す側として、何を決めておけばよいのかが見えてくる内容です。
具体的な指示文や、分担の詳細は、実験6と実験9で取り組みます。
AIに任せても、完成を確かめるのは自分、という前提で学べるようにしています。
三つ目は、制作の流れの組み立て方です。企画、制作、検品、公開という、制作の型です。
動画、Webサイト、ゲームなどを作るとき、私はこの型を繰り返し使ってきました。本書の実験そのものが、その実例です。
第8章でお話しした流れを、本編では、読者のみなさんが自分の制作に使えるように、組み立て直して学びます。型があると、作るものが変わっても、次に何をするかを考えやすくなります。実験ごとに、この型がどう形を変えるかを見ていけます。
ただし、型は、作品を保証するものではありません。私の進め方を整理したものです。
本書の実験は、すべて、実際に作った成果物がもとになっています。
動画、キャラクター、診断クイズ、Webサイト、ゲームなどを実際に制作して、その過程を記録してきました。
本編では、成果物だけでなく、制作の過程も見られます。第9章で、何ができあがったかを紹介しましたが、本編では、そこに至るまでの道のりを辿ります。うまくいったことだけでなく、途中で止まったことも含めて、記録しています。
自分の作りたいものに近い実験が、見つかるかもしれません。完成品だけを見るのとは、違う発見があると思います。
失敗したときの修正の仕方も、学べます。
私は、文字が重なる、口パクがずれる、音声が言葉を読み間違える、一か所を直したら別の表示が崩れる、といった経験をしてきました。
本編では、これらの経験を、修正の考え方として学びます。AIの完成報告だけで判断せず、実物を開いて確認すること。そして、文字数などの数字は、実測することです。
具体的な検品や測定の方法は、実験8で取り組みます。第10章の振り返りを、そのまま繰り返すのではなく、自分の制作で使える手順として整理します。
失敗をなくす方法ではなく、失敗したときに立て直す方法です。
スキルやテンプレートの活用も、学べます。
私は、AIに仕事の進め方を教えるスキルを自作して、「ひみつ道具ラボ」に整理してきました。
本編では、スキルの制作方法を、実験4で学びます。また、付録として、テンプレート集とスキル制作キットを用意しています。
テンプレートの内容は、付録で確認してください。ここでは、スキルの具体的な機能や、配布の方法には触れません。
仕事の進め方をまとめておくと、次の制作で使いやすくなります。それを、自分の秘密道具として育てていく入口になります。同じことを何度も説明し直す手間を、減らしていく工夫でもあります。
この本の到達目標は、「自分の作品を一つ、完成させて公開する」ことです。
ここでいう完成と公開は、企画、制作、検品、修正を経て、人に見せられる状態にすることです。
サイトの公開は実験5、ゲームの制作と公開は実験7で取り組みます。
ただし、学べることと、必ず実現できることは、別です。この本で学べるのは、私の実験を通して得られた、制作の進め方と型です。作品が必ず完成する、失敗しなくなる、という約束はしません。
だからこそ、私が何度もつまずいて見つけた「失敗から立ち直る検品のコツ」と、「そのまま真似できる指示のテンプレート」を、有料本編にまとめました。
それでも、読み進めながら、自分のペースで、一つずつ試してみてください。急ぐ必要はありません。
私が、Museと試行錯誤してきた道のりを、今度は、みなさんの手で辿ってもらえたら嬉しいです。
有料本編は、序章（自分だけのMuseを育てよう）と、実験1 声、実験2 口パク自己紹介動画、実験3 AI解説動画、実験4 スキル、実験5 Webサイト公開、実験6 他のAIやツールとの連携、実験7 ブラウザゲーム、実験8 検品・測定、実験9 この教科書を作る、の全10編です。
付録には、制作テンプレート集、スキル制作キット、検品・測定のチェックリストなどを収録します。詳しい目次は、第15章に掲示します。
【画像18：ここに画像が入ります ― （画像ダミー）有料本編の全体マップ図。本番では、無料パート・有料本編・付録の関係を一覧にした図が入ります。】
（画像ダミー）有料本編の全体マップ図。本番では、無料パート・有料本編・付録の関係を一覧にした図が入ります。
では、有料本編で、お待ちしています。
第11章では、この本で何が学べるのかをお話ししました。この章では、この本を、どう読んで、どう使うのかを案内します。 この本は、私が実際にMuseと試したことをまとめた、実験記録です。できあがったものだけでなく、途中の作業や修正、うまくいかなかったことも、記録しています。 読む順番は、決まっていません。最初から順番に読んでも、気になる実験から読んでも、構いません。声に興味があれば音声の実験から、Webサイトに興味があればサイト制作の実験から、入ってみてください。 ただ、実験ごとに、必要な準備がある場合もあります。作業に入る前に、その実験の案内を、一度確認してください。
実験を読むだけでなく、実際に作られた成果物も、見てみてください。 第9章で紹介した動画、診断クイズ、Webサイト、ゲームなどのうち、公開しているものは、実際にアクセスして、見たり、操作したりできます。文章だけでは分からない、画面の見え方や、作品の雰囲気を、確かめられます。 公開している作品をまとめたリンク集は、別に用意する方針です。ただ、掲載内容や公開の方法は、まだ決まっていません。公開していない作品や、制作の途中のものは、見ることができません。
本書の理解を助けるものとして、ミオちゃんの実演動画も、用意する予定です。 ミオちゃんは、DQAのAIスタッフで、これまでもニュース解説などの動画で、プレゼンターを務めてきました。文章だけでは分かりにくい作業や操作を、実演で説明できるようにしたいと考えています。 ここは、はっきりお伝えしておきます。本書用の実演動画は、現時点では、まだ制作していません。すでに制作したミオちゃんの動画とは、別のものです。 動画の本数や長さ、見られる場所や時期などは、制作と公開が確認できてから、お知らせする予定です。動画がなくても、本文と、公開している成果物で、学んでいけるようにしています。
実験記録を読んだら、自分でも、似たものを作ってみてください。これが、「再現」です。 本書には、私がどんな指示を出し、どんな成果物ができて、どう修正したのか、という制作の記録を載せる構成です。その流れを参考に、自分のMuseで試せます。 ただし、私と同じ言葉を入力しても、必ず同じ結果になるわけではありません。AIの仕様、使えるツール、作業環境、無料枠などは、変わることがあるからです。 完全に同じにすることに、こだわらなくて大丈夫です。まずは小さな部分から試して、確認して、違いがあれば直して、もう一度試してみてください。 手順を丸暗記するのではなく、制作の進め方を参考にする。それが、再現の姿勢です。
付録には、テンプレート集と、スキル制作キットを入れる予定です。 AIに仕事を頼むとき、毎回、何もないところから指示を考える必要はありません。参考になる型があれば、それを自分の目的に合わせて変えて使えます。 付録は、そうした制作を助けるための、テンプレートやスキルの素材です。ただ、具体的な内容や、ファイルの形式、受け取り方は、まだ確定していません。ですので、ここで中身を約束することは、しません。 テンプレートは、そのまま使えば必ず成功するものではありません。自分の題材に合わせて、手を入れて使うものです。付録を使わなくても、自分のペースで制作は始められます。
この本の使い方で、いちばん大切なのは、「アレンジ」です。 再現が、私の制作方法を参考にして試すことだとしたら、アレンジは、そこから、自分の目的に合った制作へ発展させることです。 私は、Museにエミリー様という名前と、司令塔の役割を与えて、DQAのAIスタッフたちと制作を進めてきました。でも、みなさんが、同じ名前や役割を使う必要はありません。自分のMuseには、使いやすい名前、性格、役割を与えてください。 私が作ったものと、同じものを作る必要もありません。制作の流れを参考に、題材やデザイン、内容を、自分の目的に合わせて変えてみてください。 もちろん、変えれば必ず成功する、とは言えません。この本は、私のやり方をなぞるためだけの本ではなく、自分なりの制作方法を考えるための本です。
実験の途中で、うまくいかないこともあると思います。 指示が伝わらない、表示が崩れる、ツールの接続や利用枠で作業が止まる。そんなときは、まず、何が起きているのかを確認してください。 第10章では、記録して、確認して、直す、という考え方を紹介しました。実験8では、測定、検品、修正の具体例を扱います。付録には、トラブル対処集を入れる予定ですが、現時点では完成しておらず、すべての問題が解決するわけでもありません。 失敗は、終わりではありません。記録を見直して、もう一度試せばいいのです。 この本を読むことが、目的ではありません。読んだことを、自分の制作に活かしてほしいのです。小さなアイデアで構いません。最初から大きな作品も、完成も、必要ありません。 まずは、自分が作ってみたいものを、一つ考えてみてください。「今度は、自分なら何を作ってみようか。」そう思えたら、もう実験は始まっています。
前章では本書の使い方をお伝えしました。ここでは、この教科書がご自身に合っているか判断できるよう、向いている方の姿を率直にお話しします。 まずおすすめしたいのは、「AIを使って自分の手で何かを作ってみたい」と考えている方です。単に日常の質問をするだけでなく、Webサイトなどの形あるものを作ってみたいと思いつつ、「本当に自分に作れるだろうか」と不安を感じているかもしれません。 私も最初は、アイデアはあってもどう形にすればいいか分からず足踏みしていました。本書は読むだけで作品が完成すると保証するものではありませんが、AIと試行錯誤しながら形にしていく現実的な手順を追っています。「作ってみたい」という意欲がある方には、確かな足がかりになるはずです。
コードや専門用語に苦手意識がある方にも、本書は向いています。「プログラミングを学ぼうとして挫折した」「英単語や記号が並ぶ画面を見るだけで身構えてしまう」という方も多いでしょう。 私自身、根っからのデザイナーでコードには強い苦手意識がありました。かつてゲームを作りたくてC言語を習ったものの早々に挫折し、今でも覚えているのは「#include」くらいです。 私でも、AIと役割分担をすることで、コードを一から書かずに制作を進められるようになりました。本書では、専門的な文法を詰め込むのではなく、日本語で意図を伝えて形にしていく進め方を共有しています。プログラムが書けなくても諦める必要はありません。
「パソコンの前に座る時間がなかなか取れない」「まずは手元のスマートフォンから試してみたい」という方にも、本書の考え方は役立ちます。高性能なパソコンが必須だと思い込み、最初の一歩をためらってしまう方もいるでしょう。 私自身、移動中などの隙間時間に、いかに手軽に制作を進められるかを模索してきました。すべての作業がiPhoneだけで完結するわけではありませんが、iPhoneはアイデアを練り、AIに指示を出す「指令拠点」として十分に活躍してくれます。 机に向かう時間がないからと諦めず、日常の隙間から始めたい方にとって、実践的なヒントが見つかるはずです。
「AIをもっと身近なパートナーとして活用したい」「自分専用のアシスタントを育ててみたい」という方にも、本書は参考になります。 私も当初は、秘書のような役割を想像してAIを使い始めました。しかし運用の過程で考えが深まり、今では「エミリー様」という司令塔（総監督）として、制作全体の進行を委ねる位置づけに落ち着いています。 もちろん、AIが人間と同じ意識や感情を持つわけではありません。それでも適切な役割と文脈を与えることで、非常に頼もしい相棒になります。自分だけのAIパートナーをどう育て、チームとして協働していくかという工夫は、本書の大きな見どころです。
AIツールに興味があっても、毎月高い利用料を払い続けることにはためらいがあるはずです。「最初から高額な投資をするのは不安だ」と感じるのはごく自然なことです。 私自身の契約状況をお伝えすると、「ChatGPT Plus」と「Google AI Pro」を契約しています。一方で、さらに高額な上位プランや特別な有償サービスには手を出していません。本書で扱うMuseも最初は無料プランから始め、紹介特典などの追加トークンも活用しながら実践してきました。「すべて無料」ではありませんが、無理のない範囲で運用しています。 高額プランを使う方を否定する気はありませんが、本書は限られたリソースの中でいかに工夫を重ねるかという実例です。身の丈に合った投資で進めたい方には、安心していただける内容です。
AIを普段の仕事の効率化や副業などの新しい挑戦に活かしたい、と考えている方も多いでしょう。 私自身、本業のデザインの現場でAIを日常的に活用しています。アイデア出しや構成案の整理など、AIを制作工程に組み込むことで、制作の視野が大きく広がりました。 ただし、明確にお伝えしておきたいのは、本書を読めば副業で必ず稼げるようになるといった約束は一切できないということです。本書には、売上や受注額といった数字の話は出てきません。 本書から学べるのは、具体的な金額ではなく、AIと協働するための実践的な考え方や、制作をスムーズに進めるための設計手順です。仕事の質を高めたい方にとって、基礎体力を養う手引きとなるはずです。
最後に、本書が向いていない方についても率直にお話ししておきます。読者の時間を無駄にしないためにも、正直にお伝えするのが誠実だと考えるからです。 まず、すぐに使える完成品だけが欲しい方や、試行錯誤の過程には興味がないという方には、本書はおすすめできません。また、プログラムの厳密な技術仕様を体系的に学びたい方や、「読むだけで簡単に副収入が得られる」といった即効性のある成果を期待する方にも合致しないでしょう。 完成品だけを求めることや、効率を最優先することは決して悪いことではなく、正当な希望です。ただ、本書は「プログラミング未経験のデザイナーが、AIと試行錯誤しながらものづくりを進める過程」を共有する本です。 もし、その過程を一緒に楽しんでみたいと感じていただけたなら、この先の章へ進んでみてください。ご自身の目指す形に合わせて、本書を役立てていただければ幸いです。