１．Prompt Engineering――「どう頼むか」を考えていた

最初の半年から７か月くらいは、ごく普通にChatGPTとチャットしていました。

「この場面を書いてください」
「もう少し自然な会話にしてください」
「主人公はそんな言い方をしません」
「ここをもっと面白くしてください」

AIが書く。私が読む。修正点を伝える。またAIが書く。

今から考えれば、これはまさにPrompt Engineeringの世界です。 つまり、 どういう入力をすれば、自分の欲しい出力を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は多ければ多いほどいいわけではありません。 必要な情報を選び、必要なタイミングで取り出し、 モデルの限られた注意を重要な情報へ向ける必要があります。

これは、私が小説を書きながら経験したことと非常によく似ています。

４．Contextを増やしたら、今度は設定同士が喧嘩した

ところが、設定ファイルを増やせば解決、というほど単純ではありませんでした。 今度は、設定同士が矛盾するという問題が起きました。

長編を書いていると、物語は変化します。 最初に決めた展開より、実際に書いて生まれた展開のほうが良かった。 キャラクターが想定と違う方向へ動いた。 作者である私自身が「こちらを正式設定にしよう」と変更することもあります。

すると、古いCharacter設定と新しいScene PlanのどちらをAIは信じればいいのか。 Timelineと古いOutlineが違っていたらどうするのか、という問題が起きます。

そこで現在は、 設定ファイル同士の優先順位を定義するファイル まで作っています。

1. 禁止事項
2. 文体の憲法
3. Glossary
4. Timeline
5. Scene Plan
6. Premise
7. Characters / Structureなど

衝突したときに何を「正」とするかをあらかじめ決め、 新しいScene PlanやTimelineで確定した内容と古い設定が食い違えば、 新しい確定情報を優先します。

５．「なんとなく違う」を文体ルールに変える

もう１つ大きかったのが、文体です。

以前は、「もう少し自然に」「説明しすぎないで」「もう少し余白を残して」と、 その都度AIに言っていました。 しかし、「自然に」という言葉はかなり曖昧です。

そこで、できる限り具体的なルールにしました。

たとえば私の小説では、

• 感情を直接書かない
• 行動、沈黙、環境描写で感情を見せる
• 平均的な文の長さを決める
• ４０字を超える文章の割合を決める
• 地の文と会話の比率を決める
• 段落の構造を決める
• 数字の表記方法を統一する
• 会話文の句点の扱いを決める
• ノートやLINEの表記方法を決める

さらに、「〜と気づいた」「〜を学んだ」「〜ということがわかった」といった、 AIがつい書きがちな説明表現も禁止しています。

以前なら出力を見て「なんとなく違う」と思っていた。 その「なんとなく」を少しずつ言葉にして、 Contextへ移していったのです。

そうすると、毎回同じ修正をAIへ伝える必要がなくなりました。

６．ChatGPTとClaudeを使い分け始める

このころから、AnthropicのClaudeも本格的に使い始めました。

私の使った感覚では、ChatGPTにはアイデアを広げたり、 物語の構成を考えたりするときの面白さがありました。 一方、Claudeには、長い文章や複数の設定を参照しながら、 日本語の本文を組み立ててもらうときの使いやすさを感じました。

• 構成やアイデアはChatGPT
• 本文はClaude
• 最後のチェックはChatGPT

という形になりました。

ところが、また問題が起きます。

AIは便利になった。 でも、人間がAIとAIの間の運搬係をしている。

これでは、まだ創作そのものに集中できません。

７．Harness Engineering――「AIが働く環境」をつくり始めた

そこでClaudeのCoworkを使うようになりました。

ここで私の関心は、 「どんなプロンプトを書けばいい文章が出るか」から、 「AIが仕事をしやすい環境をどう作るか」 へ移りました。

たとえば現在のScene Planでは、指示を３種類に分けています。

• 固定アンカー ―― 出来事の順序、日付、小道具、人物関係など、必ず守るもの
• 表現メモ ―― 作者の仮案。文体やキャラクターに合わなければ変更してよいもの
• 固定セリフ ―― 必要な場合だけ一字一句を固定するもの

すべてを固定してしまえば、AIの創造性はなくなる。 全部自由にすれば、物語が壊れる。

私は、このあたりから自分がやっていることを Harness Engineering と捉えると、とても分かりやすいと感じるようになりました。

８．Harness Engineeringも、AI業界で前面に出てきた

２０２６年２月１１日、OpenAIは 「ハーネスエンジニアリング：エージェントファーストの世界におけるCodexの活用」 を公開しました。

そこで紹介されているのはソフトウェア開発の事例ですが、 AIエージェントがコードを書く環境では、人間の役割が、 すべてのコードを直接書くことから、 環境を設計し、意図を明確にし、フィードバックループを構築すること へ変わっていく、という考え方が示されています。

OpenAIの記事では、 「Humans steer. Agents execute.」 という簡潔な表現も使われています。

モデルだけを見るのではない。 モデルに与えるツール、ドキュメント、ルール、ガードレール、評価方法、レビュー。 それらを含めた環境を整える。

もちろん、OpenAIが説明しているのはソフトウェア開発で、 私がやっているのは小説です。 規模も目的も違います。

でも、私の小説にもPremise、Characters、Timeline、Glossary、Scene Plan、 文体の憲法、禁止事項、設定ファイルの優先順位があります。 そして、それを読んで本文を書くAIがいます。

９．次に「チェックするAI」を作った

それでも、人間にはまだ仕事が残っています。 初稿のチェックです。

小説では、「文章が自然か」だけでは不十分です。

たとえば主人公のルミには、 「口が先に動く」「体が先に動く」「負けず嫌い」 「かっこよく見せたいのに、中身が追いつかない」 という特徴があります。

そこでCharacter Checkには、

• この場面で主人公が自分から動いているか
• 欲望があるか
• 弱点が出ているか
• 欲望と弱点のギャップが見えているか
• 読者が次を読みたくなるものが残っているか
• 前の問いの主人公と比べて、どこか１つ変化しているか

といった確認項目を置いています。

ここで、「このチェックもAIにやってもらえばいいのではないか」と思いました。

そこで役割の違うチェックエージェントを作りました。

• 創作性を見るエージェント
• Timelineや物語の整合性を見るエージェント
• キャラクターが生きているかを見るエージェント

それぞれが別の価値基準で原稿を読み、スコアリングする。 一定の基準に達しなければ、修正する。

１０．主人公本人にも原稿を読ませる

さらに、少し変わったことも始めました。 主人公のルミ自身を、独立したAIの役割として作ったのです。

年齢、性格、欲望、弱点、過去、人間関係。 そうした情報を持たせて、原稿を読ませます。

そして、 「あなたは、本当にここでこんなことを言いますか」 「この行動をしますか」 と聞く。

もちろん、本物のルミが存在しているわけではありません。

でも、 作者が読む。 一般的な文章評価AIが読む。 物語の主人公として読む。 という複数の視点を持つことができます。

書くAI。 時系列を見るAI。 創作を見るAI。 主人公として読むAI。

役割を分けることができます。

１１．AI業界でも「作るAI」と「評価するAI」を分け始めている

この点も、最近のAI開発の流れと重なっていました。

Anthropicは２０２６年３月２４日、 「Harness design for long-running application development」 を公開しました。

そこでは、Planner、Generator、Evaluatorを分離した ３エージェント構成が紹介されています。

特に興味深いのは、Generator自身の自己評価だけに頼るのではなく、 作る役と評価する役を分けるという考え方です。

Anthropicの事例はソフトウェア開発で、 私は小説の品質を上げようとしています。 対象はまったく違います。

それでも、 作る役と評価する役を分け、評価結果を次の生成へ戻す という構造はよく似ています。

１２．Loop Engineering――完璧な「１回」を目指さなくなった

ここまで来ると、私自身の考え方も変わりました。

最初のころは、 １回のプロンプトで、なるべく１００点に近い文章を出したい と思っていました。

でも今は違います。

２０２６年６月１６日、LangChainは 「The Art of Loop Engineering」 を公開しています。

そこでは、Agentの基本的なLoopに加えて、 出力をRubricで評価して再試行するVerification Loop、 Event-driven Loop、 さらにHarnessそのものを改善するLoopなど、 複数の反復構造が整理されています。

Loop Engineeringという言葉は、Prompt Engineeringほど長く定着した用語ではなく、 比較的新しい表現です。 しかし、私が今やっていることを説明するには、とても分かりやすい。

１回目が８０点でもいい。 評価する。直す。もう一度見る。 必要なら、もう１回直す。

人間も小説を１発で完成させるわけではありません。 初稿を書き、読み返し、編集し、校正します。 AIでも同じことができます。

そして、できれば人間が毎回コピー＆ペーストしてLoopを回すのではなく、 LoopそのものをHarnessの中へ入れる。 そこが次の段階だと思っています。

１３．設定ファイルは「物語の記憶装置」になった

このやり方を続けていると、設定ファイルの意味も変わりました。

最初は、「AIに忘れられないように設定を書いておく」程度に考えていました。 今は違います。

• Timeline ―― 物語が現在いつなのかを保持する
• Glossary ―― 日付、数値、呼称、小道具、人物関係の現在状態を保持する
• Scene Plan ―― 未来を全部固定せず、絶対に守るアンカーを保持する

そして本文が確定すれば、古い計画よりも、 実際に出来上がった確定稿を正とする。

たとえば現在の第５章では、 主人公２人の間で続いていた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を更新することが目的でもない。

私が考えたいのは、 「この人物は次にどう動くのか」 「この２人はどう変わるのか」 「この出来事を置いたら、何が起こるのか」 ということです。

１６．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が回ります。

という見方が、私には一番しっくりきます。

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を使う当事者になりたかった。 問題が起きる「現場」を、自分で持ちたかったのです。

そして実際にやってみると、

その繰り返しでした。

Chatから始まり、Projectを使い、設定ファイルを作り、 ClaudeとChatGPTを使い分け、Coworkでファイル中心の環境を作り、 評価エージェントを置き、GeneratorとEvaluatorを分け、 Loopを回すようになった。

そして現在は、ChatGPT Workでも同じ方向の環境を作れるようになってきました。

振り返ってみれば、 Prompt → Context → Harness → Loop という形になっていました。

でも、最初からこの４つの言葉を知っていて、その通りに作ったわけではありません。

小説を書きながら、 面倒だ。うまくいかない。もっと楽にしたい。 設定が壊れた。人物が違うことを言った。時系列が合わない。 毎回同じことを直すのが嫌だ。

そういう目の前の問題を１つずつ解決してきただけです。

２０．１年かけて作っていたのは、「小説」だけではなかった

今回、改めて自分の設定ファイルを並べてみて思いました。

私は１年間、小説を書いていました。 でも同時に、 AIと一緒に小説を書くための環境も作っていた。

• 作品の目的を定義するファイルがある
• 人物設定がある
• Timelineがある
• Glossaryがある
• Scene Planがある
• 文体の憲法がある
• 禁止事項がある
• 設定が衝突したときの優先順位がある
• Writerがいる
• 複数のEvaluatorがいる
• 必要なら修正し、また評価する

これはもう、単なる「ChatGPTとの会話」ではありません。

そして、それを作ったことで、ようやく私はAIを操作することから少し離れて、 物語そのものを考える場所へ戻れるようになった。

そこが、今の私にとって一番大きな到達点です。

２１．「AIとチャットする」から、「AIと働く環境をつくる」へ

ChatGPTという名前が象徴するように、 生成AIとの最初の接点は「Chat」でした。

人間が質問する。 AIが答える。 もちろん、それは今でも便利です。

でも、２０２６年の今、AIは少し違う段階に入り始めているように感じます。

質問に答えてもらう。 文章を書いてもらう。 という使い方から、

• AIにファイルを読ませる
• ツールを使わせる
• 複数の役割を持たせる
• 仕事を引き継がせる
• 評価させる
• 修正させる

という方向へ広がっています。

OpenAIはChatGPT Workを長い複数ステップの作業や完成成果物の作成向けのAgentとして展開し、 AnthropicもContext管理や長時間動くAgent Harnessの設計を公開しています。

少し大げさな言い方かもしれませんが、 そんな変化が始まっているのかもしれません。

私自身も、この１年間で、 「どういうプロンプトを書こう」 と考えるところから、

• このAIには、何を知っていてもらおう
• この役割には、何を評価してもらおう
• どのファイルを正本にしよう
• どこまでAIに任せ、どこを自分が決めよう

と考えるようになりました。

AIの性能が上がったことも重要です。 でも、それ以上に、 AIとの関係そのものが変わった。 そんな気がしています。

ちなみに、この記事自体も同じ方法で作りました。

つまりこの記事も、 Promptから始まり、Contextを与え、Harnessを使い、Loopを回して仕上げた文章 ということになります。

私はAIに小説を書かせたかったわけではなかった。 AIというものを、もっと深く理解したかった。 そのために、自分自身の「現場」が欲しかった。

小説を書くという小さな現場から始まった１年間の試行錯誤は、 ようやく、 「AIと一緒に働く環境をどう作るか」 というところまで来ました。

たぶん、ここがゴールではありません。

という流れを通って、ひとつの土台はできた。 今は、そう感じています。