AIと小説をつくる仕組み・全8回 第1回
――Prompt Engineeringから、Context Engineering、Harness Engineering、Loop Engineeringへ
約１年間、ChatGPTとClaudeを使って長編小説を制作してきました。
最初はPrompt Engineeringが中心でしたが、
設定ファイルによるContext Engineering、
AIが働く環境をつくるHarness Engineering、
そして生成・評価・修正を繰り返すLoop Engineeringへと、
私のAIの使い方は変化していきました。
この記事では、その実体験を、
２０２５年から２０２６年にかけてAI業界で起きている変化と重ねて整理します。
この記事を貫く４つの考え方
- Prompt Engineering ―― AIへの「指示」を設計する
- Context Engineering ―― AIが使う「情報」を設計する
- Harness Engineering ―― AIが働く「環境」を設計する
- Loop Engineering ―― 生成・評価・修正の「反復」を設計する
４つは世代交代ではありません。
AIに対して人間が設計する範囲が、少しずつ外側へ広がっていく
と考えると分かりやすいと思います。
去年の今ごろから、私はChatGPTを使って小説を書き始めました。
作品のタイトルは、
『13歳、わたしはお金持ちになると決めた。100の問い』
です。
１３歳の少女が「お金持ちになりたい」というところから出発し、
１００の問いとさまざまな体験を通して、ビジネス、豊かさ、
そして「よく生きるとは何か」という問いへ進んでいく長編小説です。
作品の設定ファイルには、このプロジェクトの目的を、
単に「文章を作る作業」ではなく、
「人間が変わる一回分を、物語としてシミュレートする作業」
と定義しています。
品質の基準も、「文章がうまいか」ではありません。
「人間は本当にこう変わるか」です。
ただ、最初からAIに小説を書かせること自体が目的だったわけではありません。
私が知りたかったのは、
生成AIとは、いったい何なのか。
ということでした。
ChatGPTを使えば何ができるのか。
どこまで任せられるのか。
どこから人間が考えなければならないのか。
記事を読んだり、専門家の話を聞いたりするだけではなく、
自分自身が当事者になれる「現場」を持ちたかったのです。
そこで、小説を書くことにしました。
そして約１年間、その現場で問題にぶつかるたびに、
AIを使って解決してきました。
振り返ってみると、私のAIの使い方は、
Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering
という流れで整理できます。
これは、業界で正式に決められた４段階の進化モデルではありません。
私自身の１年間を整理すると、この順番が一番しっくりくる、ということです。
ところが後から調べてみると、２０２５年から２０２６年にかけて、
AI業界でもかなり近い方向への変化が語られるようになっていました。
１．Prompt Engineering――「どう頼むか」を考えていた
最初の半年から７か月くらいは、ごく普通にChatGPTとチャットしていました。
「この場面を書いてください」
「もう少し自然な会話にしてください」
「主人公はそんな言い方をしません」
「ここをもっと面白くしてください」
AIが書く。私が読む。修正点を伝える。またAIが書く。
今から考えれば、これはまさにPrompt Engineeringの世界です。
つまり、
どういう入力をすれば、自分の欲しい出力をAIから引き出せるか
を考えることです。
もちろん、これは今でも重要です。
ところが、小説のような長いものを半年、７か月と書き続けていると、
少しおかしなことが起きました。
私は小説を書いているはずなのに、
「AIにどう伝えるか」ばかり考えるようになったのです。
AIが文章を書く
↓
私が修正する
↓
プロンプトを書き直す
↓
コピー＆ペーストする
↓
また説明して、また直す
プロンプトを書く技術は上がっていきます。
でも、創作はあまり楽しくなっていない。
本来、私が考えたかったのは、
「この人物なら、ここで何をするのだろう」
「この２人は、ここですれ違うのか」
「この出来事のあと、何が残るのか」
ということでした。
ところが実際には、AIを操作することに時間を使っている。
創作が、いつの間にか「作業」になっていました。
毎回、うまいプロンプトを書くこと以外にも方法があるのではないか。
２．Context Engineering――毎回説明することをやめた
転換点になったのは、今年の１月から２月ごろです。
小説を書いていると、毎回AIに説明していることが大量にあります。
- 主人公は誰なのか
- 何歳なのか
- どんな性格なのか
- 誰とどんな関係なのか
- 前の話で何が起きたのか
- 現在は何月なのか
- ある人物の名前を、主人公はもう知っているのか
- この言葉は、物語のこの段階で使っていいのか
こうしたことを、毎回プロンプトに書いていました。
そこで、これらをプロンプトから切り離し、
設定ファイルとして管理することにしました。
現在の私の小説プロジェクトには、たとえば次のようなファイルがあります。
- 作品全体の前提（Premise）
- 登場人物（Characters）
- 全体構成（Structure）
- 文体（Style）
- １００の問い
- 場所（Locations）
- 禁止表現（Forbidden）
- 詳細なStyle Guide
- 各章のScene Plan
- Timeline
- 友情関係の変化
- Glossary
- 小道具や生活描写のDetail
- Character Check
ここで大切なのは、ただ大量の設定を１つの巨大なファイルに詰め込んでいるわけではない、
ということです。
情報の役割を分けています。
たとえばGlossaryでは、金額や誕生日だけでなく、
「この人物の名前を主人公が知るのは問い４７から」
「Graceは声だけで、画面には映らない」
「ある小道具は現在どこにある」
といった「現在の状態」まで管理しています。
つまり、
AIに何を知っていてほしいか
だけではありません。
AIに、今はまだ何を知らないでいてほしいか
まで管理するわけです。
未来の展開をAIが知っているからといって、
現在の主人公まで知っているように書いてしまえば、物語は壊れてしまいます。
３．AI業界でも「PromptからContextへ」が語られ始めた
後から知ったのですが、このころAI業界でも
Context Engineeringという言葉が注目され始めていました。
Anthropicは２０２５年９月２９日、
「Effective context engineering for AI agents」
を公開しています。
そこでは、Prompt Engineeringの焦点が「効果的な指示をどう書くか」であるのに対し、
Agentが複数ターン・長時間にわたって仕事をするようになると、
システム指示、ツール、外部データ、会話履歴などを含め、
その時点でモデルが利用できるContext全体をどう管理するか
が重要になると説明されています。
しかも、Contextは多ければ多いほどいいわけではありません。
必要な情報を選び、必要なタイミングで取り出し、
モデルの限られた注意を重要な情報へ向ける必要があります。
これは、私が小説を書きながら経験したことと非常によく似ています。
Prompt Engineeringが「どう頼むか」だとすれば、
Context Engineeringは「AIが判断するとき、何を知っている状態をつくるか」。
４．Contextを増やしたら、今度は設定同士が喧嘩した
ところが、設定ファイルを増やせば解決、というほど単純ではありませんでした。
今度は、設定同士が矛盾するという問題が起きました。
長編を書いていると、物語は変化します。
最初に決めた展開より、実際に書いて生まれた展開のほうが良かった。
キャラクターが想定と違う方向へ動いた。
作者である私自身が「こちらを正式設定にしよう」と変更することもあります。
すると、古いCharacter設定と新しいScene PlanのどちらをAIは信じればいいのか。
Timelineと古いOutlineが違っていたらどうするのか、という問題が起きます。
そこで現在は、
設定ファイル同士の優先順位を定義するファイル
まで作っています。
- 禁止事項
- 文体の憲法
- Glossary
- Timeline
- Scene Plan
- Premise
- Characters / Structureなど
衝突したときに何を「正」とするかをあらかじめ決め、
新しいScene PlanやTimelineで確定した内容と古い設定が食い違えば、
新しい確定情報を優先します。
ここまで来ると、「長いプロンプトを書いている」というより、
AIが参照する小さな情報システムを作っている感覚に近くなりました。
５．「なんとなく違う」を文体ルールに変える
もう１つ大きかったのが、文体です。
以前は、「もう少し自然に」「説明しすぎないで」「もう少し余白を残して」と、
その都度AIに言っていました。
しかし、「自然に」という言葉はかなり曖昧です。
そこで、できる限り具体的なルールにしました。
たとえば私の小説では、
- 感情を直接書かない
- 行動、沈黙、環境描写で感情を見せる
- 平均的な文の長さを決める
- ４０字を超える文章の割合を決める
- 地の文と会話の比率を決める
- 段落の構造を決める
- 数字の表記方法を統一する
- 会話文の句点の扱いを決める
- ノートやLINEの表記方法を決める
さらに、「〜と気づいた」「〜を学んだ」「〜ということがわかった」といった、
AIがつい書きがちな説明表現も禁止しています。
以前なら出力を見て「なんとなく違う」と思っていた。
その「なんとなく」を少しずつ言葉にして、
Contextへ移していったのです。
そうすると、毎回同じ修正をAIへ伝える必要がなくなりました。
６．ChatGPTとClaudeを使い分け始める
このころから、AnthropicのClaudeも本格的に使い始めました。
私の使った感覚では、ChatGPTにはアイデアを広げたり、
物語の構成を考えたりするときの面白さがありました。
一方、Claudeには、長い文章や複数の設定を参照しながら、
日本語の本文を組み立ててもらうときの使いやすさを感じました。
- 構成やアイデアはChatGPT
- 本文はClaude
- 最後のチェックはChatGPT
という形になりました。
ところが、また問題が起きます。
ChatGPTからClaudeへコピーする
ClaudeからChatGPTへ戻す
設定ファイルを更新する
本文を保存する
Timelineを書き換える
Glossaryを書き換える
AIは便利になった。
でも、人間がAIとAIの間の運搬係をしている。
これでは、まだ創作そのものに集中できません。
７．Harness Engineering――「AIが働く環境」をつくり始めた
そこでClaudeのCoworkを使うようになりました。
パソコン側に本文や設定ファイルを置く
↓
AIがファイルを読む
↓
必要なContextを参照する
↓
Scene Planに沿って本文を書く
↓
結果を保存する
↓
確定内容を設定ファイルへ反映する
ここで私の関心は、
「どんなプロンプトを書けばいい文章が出るか」から、
「AIが仕事をしやすい環境をどう作るか」
へ移りました。
たとえば現在のScene Planでは、指示を３種類に分けています。
- 固定アンカー ―― 出来事の順序、日付、小道具、人物関係など、必ず守るもの
- 表現メモ ―― 作者の仮案。文体やキャラクターに合わなければ変更してよいもの
- 固定セリフ ―― 必要な場合だけ一字一句を固定するもの
すべてを固定してしまえば、AIの創造性はなくなる。
全部自由にすれば、物語が壊れる。
何を固定し、何をAIに考えさせるか。
その境界を設計する必要があります。
私は、このあたりから自分がやっていることを
Harness Engineering
と捉えると、とても分かりやすいと感じるようになりました。
８．Harness Engineeringも、AI業界で前面に出てきた
２０２６年２月１１日、OpenAIは
「ハーネスエンジニアリング：エージェントファーストの世界におけるCodexの活用」
を公開しました。
そこで紹介されているのはソフトウェア開発の事例ですが、
AIエージェントがコードを書く環境では、人間の役割が、
すべてのコードを直接書くことから、
環境を設計し、意図を明確にし、フィードバックループを構築すること
へ変わっていく、という考え方が示されています。
OpenAIの記事では、
「Humans steer. Agents execute.」
という簡潔な表現も使われています。
モデルだけを見るのではない。
モデルに与えるツール、ドキュメント、ルール、ガードレール、評価方法、レビュー。
それらを含めた環境を整える。
もちろん、OpenAIが説明しているのはソフトウェア開発で、
私がやっているのは小説です。
規模も目的も違います。
でも、私の小説にもPremise、Characters、Timeline、Glossary、Scene Plan、
文体の憲法、禁止事項、設定ファイルの優先順位があります。
そして、それを読んで本文を書くAIがいます。
モデル単体ではなく、モデルの周囲にある仕組みを設計する。
ここがHarnessなのだと考えると、私の試行錯誤を説明しやすくなります。
９．次に「チェックするAI」を作った
それでも、人間にはまだ仕事が残っています。
初稿のチェックです。
小説では、「文章が自然か」だけでは不十分です。
たとえば主人公のルミには、
「口が先に動く」「体が先に動く」「負けず嫌い」
「かっこよく見せたいのに、中身が追いつかない」
という特徴があります。
そこでCharacter Checkには、
- この場面で主人公が自分から動いているか
- 欲望があるか
- 弱点が出ているか
- 欲望と弱点のギャップが見えているか
- 読者が次を読みたくなるものが残っているか
- 前の問いの主人公と比べて、どこか１つ変化しているか
といった確認項目を置いています。
ここで、「このチェックもAIにやってもらえばいいのではないか」と思いました。
そこで役割の違うチェックエージェントを作りました。
- 創作性を見るエージェント
- Timelineや物語の整合性を見るエージェント
- キャラクターが生きているかを見るエージェント
それぞれが別の価値基準で原稿を読み、スコアリングする。
一定の基準に達しなければ、修正する。
もはやこれは単なる文章校正ではありません。
物語が機能しているかをAIに検査させている、という感覚に近くなりました。
１０．主人公本人にも原稿を読ませる
さらに、少し変わったことも始めました。
主人公のルミ自身を、独立したAIの役割として作ったのです。
年齢、性格、欲望、弱点、過去、人間関係。
そうした情報を持たせて、原稿を読ませます。
そして、
「あなたは、本当にここでこんなことを言いますか」
「この行動をしますか」
と聞く。
もちろん、本物のルミが存在しているわけではありません。
でも、
作者が読む。
一般的な文章評価AIが読む。
物語の主人公として読む。
という複数の視点を持つことができます。
１体の万能なAIに、全部やらせる必要はない。
書くAI。
時系列を見るAI。
創作を見るAI。
主人公として読むAI。
役割を分けることができます。
１１．AI業界でも「作るAI」と「評価するAI」を分け始めている
この点も、最近のAI開発の流れと重なっていました。
Anthropicは２０２６年３月２４日、
「Harness design for long-running application development」
を公開しました。
そこでは、Planner、Generator、Evaluatorを分離した
３エージェント構成が紹介されています。
特に興味深いのは、Generator自身の自己評価だけに頼るのではなく、
作る役と評価する役を分けるという考え方です。
Plannerが計画する
↓
Generatorが作る
↓
Evaluatorが基準に沿って評価する
↓
問題点をGeneratorへ戻す
↓
Generatorが修正する
Anthropicの事例はソフトウェア開発で、
私は小説の品質を上げようとしています。
対象はまったく違います。
それでも、
作る役と評価する役を分け、評価結果を次の生成へ戻す
という構造はよく似ています。
１２．Loop Engineering――完璧な「１回」を目指さなくなった
ここまで来ると、私自身の考え方も変わりました。
最初のころは、
１回のプロンプトで、なるべく１００点に近い文章を出したい
と思っていました。
でも今は違います。
Generate（生成）
↓
Evaluate（評価）
↓
Revise（修正）
↓
Evaluate（再評価）
２０２６年６月１６日、LangChainは
「The Art of Loop Engineering」
を公開しています。
そこでは、Agentの基本的なLoopに加えて、
出力をRubricで評価して再試行するVerification Loop、
Event-driven Loop、
さらにHarnessそのものを改善するLoopなど、
複数の反復構造が整理されています。
Loop Engineeringという言葉は、Prompt Engineeringほど長く定着した用語ではなく、
比較的新しい表現です。
しかし、私が今やっていることを説明するには、とても分かりやすい。
１回目が８０点でもいい。
評価する。直す。もう一度見る。
必要なら、もう１回直す。
大切なのは、最初の１回の出力品質だけではなく、
Loopを通った最終的な成果物の品質です。
人間も小説を１発で完成させるわけではありません。
初稿を書き、読み返し、編集し、校正します。
AIでも同じことができます。
そして、できれば人間が毎回コピー＆ペーストしてLoopを回すのではなく、
LoopそのものをHarnessの中へ入れる。
そこが次の段階だと思っています。
１３．設定ファイルは「物語の記憶装置」になった
このやり方を続けていると、設定ファイルの意味も変わりました。
最初は、「AIに忘れられないように設定を書いておく」程度に考えていました。
今は違います。
- Timeline ―― 物語が現在いつなのかを保持する
- Glossary ―― 日付、数値、呼称、小道具、人物関係の現在状態を保持する
- Scene Plan ―― 未来を全部固定せず、絶対に守るアンカーを保持する
そして本文が確定すれば、古い計画よりも、
実際に出来上がった確定稿を正とする。
作品を書きながら、Contextそのものも更新されていく。
たとえば現在の第５章では、
主人公２人の間で続いていたLINEの「パンの写真＋絵」の往復が、
ある回で止まり、数話後に再開することまで管理しています。
その一方で、「２人は傷ついている」などと感情を説明することは禁止しています。
LINEが止まったという「事実」で、２人の距離を見せる設計です。
１００話近い作品になれば、こうした情報を人間の頭だけで管理するのはかなり大変です。
しかし構造化してAIと共有すれば、
作品の記憶を、人間とAIで共有できる。
ここにもContext Engineeringの大きな意味があると思っています。
１４．そしてChatGPTにも「Chatの次」が来た
ここまでの環境は、しばらくClaudeのCoworkを中心に作っていました。
ところが２０２６年７月９日、OpenAIは
ChatGPT Work
を発表しました。
OpenAIはWorkを、より長く複雑なタスクを扱うエージェントとして位置づけています。
情報の調査・分析、接続されたアプリやファイルをまたいだ作業、
ドキュメント、スプレッドシート、プレゼンテーション、レポートなどの
完成成果物を作る用途が想定されています。
OpenAIの
ChatGPT WorkとCodexの公式説明
でも、Chatは日常的な質問や会話向け、
Workは長い複数ステップの作業や完成成果物向け、と整理されています。
これは、私にとって大きな変化でした。
それまで「このやり方はClaudeだからできる」と思っていた部分を、
ChatGPT側でも同じ方向へ持っていけるようになってきたからです。
- 同じ設定ファイルを使う
- 同じようなHarnessを作る
- 同じ評価Loopを回す
そうすると初めて、
環境の違いではなく、モデルそのものの出力の違い
を見やすくなります。
ChatGPTとClaudeのどちらが創作に向いているのか。
日本語はどう違うのか。
どちらが人物を面白く動かすのか。
それは、これからさらに見ていけると思っています。
１５．ただ、モデル比較が目的ではない
ClaudeとChatGPTのどちらが優秀なのか。
もちろん興味はあります。
でも、この１年間で私が得た一番大きなものは、そこではありません。
自分が創作を続けられる土台ができたこと。
そして、以前より創作そのものを楽しめるようになったこと。
こちらのほうが大きい。
プロンプトを書くことが目的ではありません。
コピー＆ペーストをすることが目的でもない。
Timelineを更新することが目的でもない。
私が考えたいのは、
「この人物は次にどう動くのか」
「この２人はどう変わるのか」
「この出来事を置いたら、何が起こるのか」
ということです。
設定ファイルも、エージェントも、HarnessもLoopも、
人間が本来考えたいことへ戻るための仕組みなのだと思っています。
１６．Prompt → Context → Harness → Loopは「世代交代」ではない
ここで１つ、誤解しないようにしておきたいことがあります。
私は、「Prompt Engineeringは古い。これからはContext Engineeringだ。
その次はHarness Engineering、その次はLoop Engineeringだ」
と言いたいわけではありません。
４つは置き換わっているのではなく、重なっています。
-
Prompt Engineering
AIへの「１回の指示」を設計する
-
Context Engineering
AIが「何を知った状態で考えるか」を設計する
-
Harness Engineering
AIに「どんな環境、ファイル、ツール、役割、ルールを与えて働かせるか」を設計する
-
Loop Engineering
「生成、評価、修正をどう循環させ、最終品質を上げるか」を設計する
Promptは今でも必要です。
そのPromptもContextの一部になります。
ContextはHarnessの中で使われます。
Harnessの中でAgentが動き、その内外でLoopが回ります。
AIに対して人間が設計する範囲が、少しずつ外側へ広がった。
という見方が、私には一番しっくりきます。
AnthropicがContext Engineeringを論じ、
OpenAIがHarness Engineeringを論じ、
AnthropicがGeneratorとEvaluatorを分離したHarnessを実験し、
LangChainがLoop Engineeringを論じる。
２０２５年から２０２６年にかけて、
AI開発の関心が「良いモデル＋良いプロンプト」だけではなく、
Agentが働く環境や評価の仕組みまで含めたシステム設計へ広がっている
ことが見えてきています。
１７．これは、小説だけの話ではないと思う
最近、この仕組みは小説だけのものではないと思うようになりました。
たとえば、
- マニュアルを書く
- 教材を作る
- レポートを書く
- 企画書を作る
- Web記事を書く
こうした仕事にも、
情報を集める
↓
構成を決める
↓
初稿を作る
↓
評価する
↓
修正する
という工程があります。
だったら、
調べるAI、構成を考えるAI、文章を書くAI、
事実関係を見るAI、読み手の立場から評価するAI、
という役割分担もできます。
そして、その周囲にContext、Harness、Loopを作る。
おそらく画像でも、動画でも、音楽でも、
具体的なツールは違っても、
考え方には共通するところがあるのではないかと思います。
１８．もっと先へ進む道も見えている
ここから、さらに環境を作り込むこともできます。
- APIを使う
- 複数のモデルをプログラムでつなぐ
- 自分専用のオーケストレーションを作る
- ローカルPCや自分のサーバー上で、小さな言語モデルを動かす
- モデルを役割ごとに使い分ける
- 必要な品質を、もっと低いコストで作れる環境を構築する
そういう方向も見えてきました。
ただ、今の私の目的は小説を書くことです。
趣味の延長で創作を楽しむというレベルなら、
必ずしもそこまで大がかりな仕組みを作る必要はないとも思っています。
今あるサービスと１台のパソコンだけでも、かなり高度なところまで来られる。
むしろ、そこが今とても面白いところです。
１９．私は、AIを理解するための「現場」が欲しかった
そもそも、なぜ１年もこんなことをしてきたのか。
私はAIについて外から評論したかったわけではありません。
AIを使う当事者になりたかった。
問題が起きる「現場」を、自分で持ちたかったのです。
そして実際にやってみると、
問題が起きる
↓
AIで解決する
↓
次の問題が出てくる
↓
また仕組みを変える
その繰り返しでした。
Chatから始まり、Projectを使い、設定ファイルを作り、
ClaudeとChatGPTを使い分け、Coworkでファイル中心の環境を作り、
評価エージェントを置き、GeneratorとEvaluatorを分け、
Loopを回すようになった。
そして現在は、ChatGPT Workでも同じ方向の環境を作れるようになってきました。
振り返ってみれば、
Prompt → Context → Harness → Loop
という形になっていました。
でも、最初からこの４つの言葉を知っていて、その通りに作ったわけではありません。
小説を書きながら、
面倒だ。うまくいかない。もっと楽にしたい。
設定が壊れた。人物が違うことを言った。時系列が合わない。
毎回同じことを直すのが嫌だ。
そういう目の前の問題を１つずつ解決してきただけです。
私にとってこれらの言葉は単なるAI用語ではありません。
なぜ、その技術が必要になるのかを、自分の現場で経験した結果についた名前なのです。
２０．１年かけて作っていたのは、「小説」だけではなかった
今回、改めて自分の設定ファイルを並べてみて思いました。
私は１年間、小説を書いていました。
でも同時に、
AIと一緒に小説を書くための環境も作っていた。
- 作品の目的を定義するファイルがある
- 人物設定がある
- Timelineがある
- Glossaryがある
- Scene Planがある
- 文体の憲法がある
- 禁止事項がある
- 設定が衝突したときの優先順位がある
- Writerがいる
- 複数のEvaluatorがいる
- 必要なら修正し、また評価する
これはもう、単なる「ChatGPTとの会話」ではありません。
小さいけれど、自分専用のAI創作環境になっています。
そして、それを作ったことで、ようやく私はAIを操作することから少し離れて、
物語そのものを考える場所へ戻れるようになった。
そこが、今の私にとって一番大きな到達点です。
２１．「AIとチャットする」から、「AIと働く環境をつくる」へ
ChatGPTという名前が象徴するように、
生成AIとの最初の接点は「Chat」でした。
人間が質問する。
AIが答える。
もちろん、それは今でも便利です。
でも、２０２６年の今、AIは少し違う段階に入り始めているように感じます。
質問に答えてもらう。
文章を書いてもらう。
という使い方から、
- AIにファイルを読ませる
- ツールを使わせる
- 複数の役割を持たせる
- 仕事を引き継がせる
- 評価させる
- 修正させる
という方向へ広がっています。
OpenAIはChatGPT Workを長い複数ステップの作業や完成成果物の作成向けのAgentとして展開し、
AnthropicもContext管理や長時間動くAgent Harnessの設計を公開しています。
「AIとチャットする時代」から、
「AIが働く環境を設計する時代」へ。
少し大げさな言い方かもしれませんが、
そんな変化が始まっているのかもしれません。
私自身も、この１年間で、
「どういうプロンプトを書こう」
と考えるところから、
- このAIには、何を知っていてもらおう
- この役割には、何を評価してもらおう
- どのファイルを正本にしよう
- どこまでAIに任せ、どこを自分が決めよう
と考えるようになりました。
AIの性能が上がったことも重要です。
でも、それ以上に、
AIとの関係そのものが変わった。
そんな気がしています。
ちなみに、この記事自体も同じ方法で作りました。
人間である私が１年間の体験を話す
↓
AIと一緒に構成する
↓
小説の実際の設定ファイルをContextとして読み込ませる
↓
AI業界の最近の動きを確認する
↓
文章を組み直す
↓
最後は人間である私が判断する
つまりこの記事も、
Promptから始まり、Contextを与え、Harnessを使い、Loopを回して仕上げた文章
ということになります。
私はAIに小説を書かせたかったわけではなかった。
AIというものを、もっと深く理解したかった。
そのために、自分自身の「現場」が欲しかった。
小説を書くという小さな現場から始まった１年間の試行錯誤は、
ようやく、
「AIと一緒に働く環境をどう作るか」
というところまで来ました。
たぶん、ここがゴールではありません。
Prompt → Context → Harness → Loop
という流れを通って、ひとつの土台はできた。
今は、そう感じています。
