第1章でも少し触れましたが、私はプログラミングがまったくできません。若い頃にC言語の入門書を開いてみたものの、すぐに挫折してしまい、いま覚えていることといえば冒頭に書く「#include」という文字列くらいです。デザイナーとしての経験は長く積んできましたが、コードを自分で組み立てる技術は持ち合わせていません。
そんな私が、自分の手でゲームを作り、届けることなどできるのでしょうか。言葉で指示を出せばコードが出力される時代になりましたが、それは「専門的な知識や配慮が完全に不要になった」という意味ではありません。
しかし、「自分でコードを書く能力」と、「どのようなゲームにしたいのかを構想し、出来上がった動きを確認して判断する能力」は、明確に別のものです。コードの実装をMuseに任せることができたとしても、遊ぶ人の立場で画面を眺め、手触りを確かめる役割は人間側に残ります。コードが書けない私でも、仕様を言葉で整理し、Museと対話を重ねながら進めることで、ブラウザで遊べるゲームを形にできるのか。その疑問を解き明かすために始めたのが、今回の実験です。
ゲーム制作を始めるにあたって、最初に決めたのは「完成させる範囲を徹底的に小さく絞り込む」ということでした。ゲーム開発は、油断するとすぐに構想が膨らんでしまいます。凝ったストーリーや複雑な仕掛けを最初から盛り込もうとすると難易度は跳ね上がり、プログラミングができない人間にとっては検証すら困難になります。
そこで今回の企画では、中心となる遊びを「30秒間タップして遊ぶ」という、単純でわかりやすい一点のみに定めました。ルールが複雑であればあるほど裏側の仕組みも複雑になり、不具合の原因特定も難しくなります。制限時間の中で画面をタップするという明快な核があれば、遊ぶ人にも直感的に伝わりやすく、確認すべき項目も最小限に抑えられます。
この中心となる遊びを決めた上で、ゲームのタイトルを「ドタバタタップ」と名付けました。制作に用いるゲームエンジンには、Webブラウザ向けへの書き出しに対応しているGodotを選びました。壮大な大作を目指すのではなく、自分自身の手で最初から最後まで見届けられる小さな規模に留めること。これが今回の企画の最大の要でした。
企画の骨組みが定まったら、次はMuseへの制作依頼です。しかし、頭の中の大雑把なイメージをそのまま投げかけるだけでは、意図通りのゲームは生まれません。どんなゲームを作りたいのかをまとめた「仕様書」が不可欠です。
仕様書と聞くと、専門用語が並んだ難解な書類を想像するかもしれませんが、ここで必要なのはコードの設計図ではありません。画面上に何を表示するのかを、言葉で整理した案内板のようなものです。
私はMuseと対話しながら、中心となる「30秒間タップして遊ぶ」というルールを土台に、ゲームの開始から終了までの流れや、タップ操作を受け付ける仕組みを文章化していきました。仕様書のテンプレートの詳細は本書の付録Bに正本としてまとめていますが、本文の段階では、まず「何を画面に出し、プレイヤーのどんな操作に対して、どう応えるのか」を書き出すことに集中しました。
仕様書を作る工程は、自分の頭の中の曖昧な思い込みを可視化する作業でもありました。言葉として定義されていなければ、Museも何を形にすべきか判断できません。依頼の基準となる仕様書を固めることが、その後の制作を支える土台となりました。
ゲームの仕様が定まったら、次はゲームの世界観を形づくる素材の準備です。ゲームを構成する主な要素には、キャラクターや背景といったビジュアル、そして遊んでいるときの心地よさを生み出す音素材があります。
私たちの制作チームであるDQAでは、日頃からキャラクターイラストの制作や、ゲーム用の音素材の制作を行っています。今回の「ドタバタタップ」でも、そうした日々の活動の中で作られてきた素材を活用することにしました。もちろん、手元にある制作済みの素材をすべてこのゲームに詰め込んだわけではありません。「30秒間タップして遊ぶ」という小さなブラウザゲームの世界観に合い、プレイヤーの邪魔にならないものを選んで画面に配置することを目指しました。
素材を準備する際、コードが書けない人間であっても、デザイナーとしての視点は活かすことができます。画面全体の配色のバランス、タップした瞬間に視覚的な反応がわかりやすいか、音が鳴ることで手応えが感じられるかといった要素は、プログラムの知識とは別の感覚的な調整です。Museに実装を依頼しつつ、私はそれらの素材が画面上で調和するかどうかを意識しながら準備を整えていきました。
仕様書と素材が揃い、Museによって組み立てられたゲームを受け取ったら、いよいよ実際に動かしてみる段階です。ここで重要なのは、「ゲームが起動すること」と「ゲームとして正常に動くこと」は別物であるという点です。エラーが出ずに画面が立ち上がっても、それだけでゲームが完成したわけではありません。画面が表示されても、操作を受け付けなかったり、意図した時間で進行しなかったりすれば、ゲームとして成り立っていません。
確認の観点は3つです。第一に、画面全体のレイアウトが崩れず、意図した位置に要素が表示されているかという「画面表示の確認」。第二に、画面をタップした際に意図した通りの反応が返ってくるかという「タップ操作の受け付け」。第三に、開始から制限時間が終わるまでの一連の流れが破綻せず、「30秒のゲームとして成立しているか」という進行の確認です。
また、制作環境の画面上だけで満足するのではなく、最終的にプレイヤーが触れるブラウザ上で動くかどうかも大切です。すべてのブラウザや端末での完全な動作を保証することは困難ですが、まずは想定している基本的な環境で遊べるかどうかを見極める必要があります。
しかし、実際の制作現場は、最初からすんなりと運ぶほど甘くはありません。Museからプロジェクトを受け取り、期待に胸を膨らませて動かしてみると、思った通りには動いてくれないという現実に直面しました。
画面自体は表示されるものの、仕様書で思い描いた通りの挙動をしてくれないのです。どこをどう見直せばよいのか、コードの細部を読み解けない私にとっては、思いがけない挙動を見るたびに大きな不安が押し寄せてきました。「やはり、プログラミングができない人間がゲームを作るなど無謀だったのではないか」という弱気が頭をよぎりました。
ですが、ここで立ち止まってしまっては実験になりません。プログラミングができないからこそ、私は「なぜ思い通りに動かないのか」を観察することに徹しました。コードを直接修正できなくても、「仕様書に書いたどの部分と、現在の画面の動きが食い違っているのか」を発見することはできます。画面の中で起きている現象を冷静に見つめ、何が意図と違っているのかを整理して、再びMuseに問いかける準備を進めました。思い通りに動かないという失敗は、行き止まりではなく、完成へ向けた調整作業の第一歩だったのです。
思ったように動かない原因を探るため、私はMuseとの間で動作確認と修正のやり取りを何度も繰り返しました。コードが書けない私にできるのは、実際にゲームを動かし、仕様書と現実の動作を見比べ、違いを正確な言葉にして伝えることです。
「ここが動かない」と感情的に伝えるだけでは、AI側もどこを直せばよいのか判断できません。どのような操作をしたときに画面上で何が起き、本来の仕様ではどう動くべきだったのか。そうした事実関係を客観的に記述し、修正の依頼として投げかけます。
修正されたプロジェクトを受け取ったら、再び手元で起動し、同じ操作で確認します。一つの問題が解消されても、別の部分で仕様との食い違いが見つかることもあります。そうした確認と修正のサイクルを一つずつ進めていきました。この過程で強く実感したのは、AIを活用した開発で最も求められるのは、華麗なプログラミング技術ではなく、地道に事実を観察し、言葉で的確にフィードバックを返す忍耐強さだということです。
確認と修正を重ねた結果、ゲームは徐々に安定し、仕様書で思い描いた「30秒間タップして遊ぶ」という形へと近づいていきました。
動作確認と修正を重ねた「ドタバタタップ」は、GitHub Pagesを用いてWeb上に公開し、現在も遊べる状態で公開を続けています。ブラウザからアクセスするだけで誰でも遊べる状態になり、ゲーム制作の第一段階は達成できました。
しかし、ゲームが完成して公開できたとしても、それだけでは終わりません。どんなに面白いゲームを作っても、その存在を知ってもらい、遊び方を分かりやすく伝えなければ、多くの人に楽しんでもらうことはできません。ここで私は、「ゲームを作ること」と「その魅力を分かりやすく伝えること」は、まったく別の制作工程であるという事実に直面しました。
そこで私は、公開したゲームを知ってもらうため、紹介を目的とした解説動画の制作に着手しました。動画の制作にあたっては、演出用の架空の映像ではなく、実際にWeb上で動いている「ドタバタタップ」のゲーム画面のスクリーンショットを素材にしました。本物のプレイ画面をありのままに見せることが、ゲームの内容を最も素直に伝える方法だと考えたからです。
ところが、この解説動画の制作においても、最初のバージョン（v1）で思わぬ失敗をやらかしてしまいました。ゲーム本体の不具合ではなく、動画の画面構成における設計ミスです。
完成した解説動画v1をプレビューしてみたところ、画面の下部に配置した字幕のテキストと、注目ポイントを強調するために配置したマーカーが、見事に重なってしまっていたのです。
文字の上に強調用のグラフィックが被さってしまったため、字幕が非常に読みづらく、視覚的な情報が散らかって見えました。ゲームの魅力を分かりやすく伝えるために作ったはずの動画が、重なりによって視聴者に余計なストレスを与えるものになっていたのです。
静止画のデザインであれば、要素同士の重なりにはすぐに気づけます。しかし、動画のように時間軸に沿って複数の要素が現れたり消えたりする媒体では、それぞれの配置や表示タイミングが重ならないよう、動的な視点での配慮が必要です。ゲーム画面のスクリーンショットを活かそうとするあまり、解説用の要素同士が画面内でどう干渉するかという確認が疎かになっていたことを、深く反省させられた出来事でした。
字幕とマーカーが重なってしまうというv1の問題を受け、私は動画の改修作業に取りかかりました。目指したのは、解説の言葉とゲームの画面が無理なく自然に目へ入ってくる状態です。
実験3で学んだ「文字や情報の重なりを避ける」という確認の物差しに照らして、動画全体を見直していきました。具体的にどの要素をどう変更したかという改修の詳細は記録の範囲を超えるため触れませんが、文字が読みやすいか、強調したいゲーム画面の要所が見えているかを確かめながら作業を進めました。
こうしてv1の重なり問題に対処し、2026年11月1日に完成させたのが「解説動画v2」です。動画の長さは約180秒（3分）です。もちろん、このv2によってあらゆる課題が完全に解決したとまでは言えませんが、v1で生じていた重なりは解消され、人に見ていただくに堪える一つの形になりました。ゲーム本体を作る工程と同様に、伝えるための動画制作においても、確認と修正を地道に積み重ねることが不可欠なのだと身をもって学びました。
今回の実験を通じて、私たちは大きく分けて2つの成果物を形にすることができました。
1つ目は、ブラウザゲーム「ドタバタタップ」です。プログラミングができない私が仕様書を作成し、Museとの協調によってGodotで形にし、GitHub Pagesを通じてWeb上に公開した30秒間のタップゲームです。このゲームは現在も公開中であり、ブラウザを通じて実際に遊んでいただくことができます。アクセス先は、本書の巻末の作品リンク集でご案内しています。
2つ目は、そのゲームを紹介するために制作した「解説動画v2」です。実際のゲーム画面のスクリーンショットを用いながら、v1での字幕とマーカーの重なりという失敗を乗り越えて、約180秒の映像として2026年11月1日に完成させました。なお、この解説動画v2の一般公開の状態については未確定です。
質の異なる2つの制作物を最後まで完走できたことは、コードが書けない私にとって大きな自信となりました。
本書とあわせて、ミオちゃんによるゲーム制作の実演動画も用意する予定です。
テキストの解説だけでは、言葉のやり取りを通じてどのようにゲームの骨組みが作られていくのか、その空気感までは掴みにくい部分があるかもしれません。そこで、Museにどのように指示を出し、出力されたものをどう確認し、修正を重ねていくのかという一連の流れを、映像として追体験していただけるような実演動画を想定しています。
なお、この実演動画は、先ほどご紹介したゲームの解説動画v2とは別の制作物として新たに用意するものです。
最後に、Museと一緒にブラウザゲームを制作し、検品するための再現手順をまとめます。編集上の手順案であり、私が歴史的にこの順序通りに進めたわけではありません。
手順の骨子は、次の12ステップです。
1. 中心となる遊びを決める：核となる楽しさを一つに絞ります。 2. 完成範囲を小さくする：最短で完成できる規模にします。 3. 操作方法や必要な画面を整理する：操作と画面の切り替わりを整理します。 4. 仕様書を作る：「何を画面に出し、操作に対してどう動くか」を文章化します。 5. Museへ依頼する：仕様書を提示し、実装を依頼します。 6. 素材を用意する：キャラクターや背景、音素材を準備します。 7. 実際に起動して操作する：表示や操作の受け付けを確かめます。 8. 仕様と異なる部分を確認する：仕様書と食い違う現象を洗い出します。 9. 修正を依頼する：現象と本来あるべき動作の差分を言葉で伝えます。 10. 修正後にもう一度動かす：解消されたか再確認します。 11. 公開先で実際に遊べるか確認する：公開環境のブラウザで遊べるか確かめます。 12. 成果物と修正内容を記録する：仕様と修正の経緯を残します。
ゲームが完成したら、次は「動くことを確認する」段階から、データや基準に基づいた検証へと目を向けます。実験8では、そうした「確認から測定へ」というステップへ進みます。
AIと共同で制作を進めていると、作業の終盤に「ご指定の通りに作成しました」「これで完成です」という言葉が返ってきます。画面に整った文章やコードが表示されると、つい作業がすべて終わったような安心感を抱いてしまいがちです。
しかし、AIが告げる「完成しました」という言葉は、指示された処理やファイルの生成を終えたという報告にすぎません。その成果物が利用者の手元に届いたとき、意図した通りに正しく動作するのか、中身に不整合や見落としがないのかといった品質までを、その一言は保証してくれません。
どれほど賢いAIであっても、出力された結果の良し悪しを最終的に判断し、利用者に届ける責任を背負うのは私たち人間です。相手が自信たっぷりに仕上げてくれたように見えても、決して鵜呑みにはせず、立ち止まって確かめる姿勢が欠かせません。AIの報告を文字通りの完成として受け取るのではなく、ここからが人間による検品の始まりであると捉えることが、大切な出発点になります。
AIとのやり取りを終えたあとに最初に行うべきことは、生成された成果物を自分の目で確認することです。対話画面のテキストやプレビューを眺めるだけでなく、出力されたファイルを実際の利用環境に置き、実物を動かして確かめる必要があります。
たとえば実験2の動画制作では、キャラクターの口型の位置を、フレームや画面上の座標を測りながら確認しました。また、実験5でWebサイトを制作した際にも、公開処理が終わったという通知をそのまま信じるのではなく、公開されたページへ実際にブラウザからアクセスし、正しく表示されているかを確かめています。
AIが生成したコードやデータは、外部の環境や実際の画面に置かれた瞬間に、思わぬ崩れや不具合を見せることがあります。画面をスクロールして端まで見渡す、リンクをクリックしてみる、実際の文字数を計測してみるなど、確かめる手間を惜しんではいけません。テキストの表面だけをなぞるのではなく、実際の環境で動く姿を自分の目で確かめることこそが、検品の最も基本的な土台となります。
成果物の確認をすべて人間の目視だけで処理しようとすると、確認漏れが生じたり、膨大な確認作業に追われて疲弊したりすることがあります。そこで有効になるのが、制作を担当したMuse自身にも検品の役割を担ってもらう方法です。
ただし、単に「間違いがないか確認してください」と大雑把に頼むだけでは、AIは「問題ありませんでした」と表面的な返答を返してくることが少なくありません。AIに検品を依頼するときは、何を基準として、どの部分を確かめてほしいのかを、機械的に判定できる指示として提示することが重要です。
たとえば、文章であれば「指定した見出し構成がすべて揃っているか」「文字数が指定した範囲内に収まっているか」といった、数値や形式で確認できる項目を数えさせます。
人間が設計した確認基準をMuseに渡し、機械的に点検できる部分を洗い出してもらうことで、検品の精度は高まります。ただし、Museが返してきたチェック結果についても、最終的な裏付けを取るのは人間側の役割であることを忘れてはなりません。
検品の重要性を実感する事例として、実験5で公開した「集中力スタイル診断」の検証作業を取り上げてみます。この診断は、利用者が7つの質問に答えることで、自分の集中力の傾向が5つのタイプ（「一点突破」「並行回遊」「助走長め」「風まち」「多刀流」）のいずれかに分類されるWebコンテンツです。
Webサイトとして公開した直後は、設問がきちんと表示され、ボタンを押せば診断結果の画面へスムーズに遷移していたため、一見すると何の問題もなく仕上がっているように見えました。しかし、表面的に動いていることと、内部のロジックが意図通りに機能していることは全くの別問題です。
7問の質問に対して、利用者がどの選択肢を選ぶかによって、最終的な判定タイプは変化します。もし配点や計算の仕組みに歪みがあれば、特定のタイプばかりが表示されたり、ほとんど出現しないタイプが生まれたりしている可能性があります。
そこで私たちは、この診断が内部的にどのような結果を出力するのか、客観的な数値として測定してみることにしました。これは実際の利用者にアンケートを取って回答を集めた調査ではありません。診断ロジックそのものが持つ傾向を明らかにするため、プログラムを用いて約10万回の試算（シミュレーション）を行いました。測定の実行には、必要に応じて外部のスクリプトやプログラム環境を組み合わせています。
約10万回の試算を実行し、各タイプの出現結果を集計してみたところ、明確な偏りが浮かび上がってきました。測定によって得られた出現率は、次の通りです。
・一点突破：26.1％ ・多刀流：25.2％ ・風まち：20.7％ ・助走長め：20.6％ ・並行回遊：7.5％
なお、各数値は小数第1位で丸めているため、合計すると100.1％になります。これは丸めによる計算上の差です。
この測定結果で誰もが気づくのは、「並行回遊」というタイプの出現率がわずか7.5％にとどまっているという事実です。上位の「一点突破」や「多刀流」がそれぞれ全体の4分の1を超える割合を占めているのに対し、並行回遊だけが極端に低い値を示していました。
もしも私たちが、ブラウザ上で数回ほど自分でボタンを押して動作確認をしただけで満足していたら、この偏りに気づくことはなかったでしょう。人間が手作業で数回試した程度では、「たまたまこのタイプが出たのだろう」と思い込んでしまい、全体の傾向は捉えられません。
約10万回というまとまった回数の試算を行い、機械的に結果を集計したからこそ、感覚や思い込みに惑わされることなく、成果物が持つ客観的な性質を浮き彫りにすることができました。測定した結果を数値として手元に置くことの価値がここにあります。
なぜ、これほどまでに「並行回遊」の出現率が低くなってしまったのでしょうか。私たちはMuseとともに、診断クイズの設問と配点の設計を、1問ずつ確認していきました。
その結果、設問の構造に明確な要因が存在していることが判明しました。この診断は全部で7つの設問で構成されていますが、そのうち「Q2」と「Q5」の2つの設問において、どの選択肢を選んでも「並行回遊」タイプに配点が加算されない設計になっていたのです。
並行回遊は、7問のうち2問では、どう答えても点数を獲得できない状態に置かれていたのです。7問中5問でしか点数を獲得できないのですから、合計得点で競い合った際に、並行回遊が最終結果として選ばれる確率が構造的に下がるのは当然の成り行きでした。
ただし、注意しなければならないのは、この配点構造の事実だけで、出現率が7.5％になったという数値のすべてを説明できると断定してはならないという点です。複数の要素が絡み合って最終的なパーセンテージが形作られているからです。
大切なのは、「出現率が低い」という測定結果の背後に、どのような構造的な理由が潜んでいたのかを突き止めることです。理由が明らかになって初めて、この現象にどう向き合うべきかを検討できます。
設問の構造と出現率の偏りが明らかになったとき、多くの人は「すぐにバグとして修正し、5つのタイプが均等に出るように配点を直すべきだ」と考えるかもしれません。しかし、出現率に偏りがあること自体が、直ちに制作物としての欠陥や失敗を意味するわけではありません。
そもそもこの診断を設計した段階で、「5つのタイプがすべて20％ずつ均等に出現しなければならない」という目標を設定していたわけではありません。現実の仕事の現場でも、特定のスタイルが多勢を占め、別のスタイルが少数派であることは自然なことです。もし均等に出現することを過剰に求めて配点を無理にいじってしまえば、診断としての面白さや、設問と結果の納得感がかえって損なわれてしまう恐れすらあります。
私自身、この仕組みと結果についてMuseから詳しい説明を受け、その理由に納得しました。そして熟考した結果、この配点の偏りを修正するかどうかについては、現時点では判断を保留することにしました。修正するとも、このまま維持するとも決めつけず、慎重に扱うという判断です。測定した客観的な事実と、それをどう扱うかという人間の意思決定を明確に切り離して考えることが、検品における極めて重要な姿勢です。
制作物を安全に運用していくための取り組みとして、私たちは「ヒヤリハット」の記録を実践しています。ヒヤリハットとは、重大な事故やトラブルには至らなかったものの、「一歩間違えれば危なかった」という危険な出来事を、日付とともに追記形式で記録していく活動です。
たとえば私たちの現場でも、次のようなヒヤリハットの実例がありました。
1つ目は、Webサイトの更新作業において、古いバージョンのソースファイルを使って公開処理を進めてしまいそうになった事例です。そのまま実行していれば、すでに公開されていた既存のページが消えてしまう危険がありました。実際には消えておらず、未遂で済みました。
2つ目は、外部サービスとの連携に必要なAPIトークンを入力したつもりが、登録されていなかった事例です。設定を終えたと思い込まず、値を読み戻して確認したことで、未登録であることがその場で判明しました。
こうした出来事を「何も起きなくてよかった」と流してしまうと、いずれ同じミスを繰り返して本当の事故を引き起こしてしまいます。事故の一歩手前で踏みとどまった経験こそ、貴重な学びの源泉です。危険な兆候を逃さず記録し、再発を防ぐための作業ルールへと変えていくことが、制作全体の安全性を高めてくれます。
成果物の品質を最終的にどう判定するかは、ものづくりにおける永遠のテーマです。検品を重ねていると、細かな数値の揺れや小さなズレがどうしても発生します。そうした一時的な変動にその都度振り回されて慌てて修正を加えていては、全体の整合性が崩れてしまいます。
私たちが大切にしている品質判定の考え方は、短期的な小さな数字の揺れに一喜一憂して結論を急ぐのではなく、一定の期間やまとまった試行を通じて蓄積された合計値を見て判断を下すというアプローチです。
そのためには、あらかじめ「いつの時点で判定を行うか」という日時や条件を先に決めておく運用が効果的です。判定のタイミングを事前に定めておくことで、場当たり的な修正に走るのを防ぐことができます。
また、品質の判定においては、「何をもって合格とするか」の基準を人間が明確に意識しておく必要があります。AIに頼めば無数の改善案を提示してくれますが、すべて反映することが常に正解とは限りません。利用者が安全に使えるか、目的に対して十分な誠実さを保てているかという観点から、最終的な合否を下すのは人間の役割です。測定結果を冷静に眺めつつ、最後に責任を持って品質の印鑑を押すのは人間であるという自覚が、安定した成果物を生みます。
検品の結果を次の制作や改善へつなぐためには、検証結果を書類としてまとめておくことが不可欠です。私たちは検品の実践を通じて、「検証記録」と「品質判定シート」という形で成果物を取りまとめています。
検証記録には、どのような環境や手順で測定を行ったのか、その結果どのような数値が得られたのかという客観的な事実を、主観を挟まずに記述します。今回の診断クイズであれば、プログラムによって約10万回の試算を行ったこと、各タイプの出現率が何％であったかという計測値をそのまま記載します。
一方の品質判定シートは、得られた数値を前にして、人間がどのような根拠でどのような判断を下したのかを記録する場所です。「偏りの原因は設問構造にあることを確認した」「現状では修正を行わず判断を保留とする」といった意思決定を、将来の自分が振り返られるように書き残します。
これらの記録やシートの正式項目については、本書の「付録E」に正本として整理して掲載しています。検品を自分たちの作業に導入する際は、付録Eの書式を手本として、事実の記録と意思決定の記述を整理してください。
本書とあわせて、ミオちゃんによる成果物の検品実演動画も用意する予定です。
テキストや図解を読むだけではイメージが掴みにくい、実際の画面操作や確認の所作を、映像を通して直感的に理解していただけるような内容を企画しています。AIに対してどのように検品を依頼し、出力された結果を人間がどのように受け止め、合否を判断していくのか、その一連の流れをお見せする予定です。
最後に、読者のみなさんがご自身の制作現場で検品を再現できるように、編集上の再現手順案として、品質管理（QC）と改善のステップをまとめました。私がすべての制作で常にこの順序を厳密に踏んでいるというわけではありません。チェックリストの正式項目は付録Eに正本を掲載しています。
1. 対象となる成果物を決める：文章、Webページ、画像、動画、プログラムなど、何を点検するのかを定めます。 2. 完成の判断基準を整理する：どのような状態になれば「完成」とみなせるのか、基準を書き出しておきます。 3. 実際の成果物を開いて確認する：AIの報告を鵜呑みにせず、実際の利用環境で成果物を直接開き、自分の目で確認します。 4. 数値で測れる項目は機械的に測定する：文字数や設定値、計算ロジックなどをツールやプログラムで測定します。 5. 測定結果を記録する：得られた数値を感想と混ぜず、ありのまま書き留めます。 6. 基準と比較する：判断基準と測定結果を照合し、想定外のズレがないかを比べます。 7. 問題があれば原因や構造を調べる：想定と異なる結果が見つかったら、AIとともに原因を調査し、構造のどこに要因があるかを突き止めます。 8. 修正するか・維持するか・判断を保留するかを検討する：問題を機械的にすべて直そうとせず、直すべき不具合か、そのままにする性質か、保留すべきかを人間が検討します。 9. 修正した場合は再度検品する：修正で別の不具合が起きていないかを含め、再び測定と確認を行います。 10. ヒヤリハットや判定理由を記録する：事故になりかけた経験や、判定の根拠を追記形式で残します。 11. 次回の確認日や判定条件を必要に応じて決める：保留にした項目は、次回の確認日や見直しの条件を決めておきます。
こうして測定と判定の進め方を確立できたことで、私たちの制作はまた一段、確かな手応えを得ました。続く実験9では、実験の集大成として、この教科書そのものを制作していく実践の記録へと進みます。