記事一覧

2026-09-16 22:00:00

AIに任せる仕組みを作って、最後に残った時間 — 「文明の夜明け」の先で考えること

AIと小説をつくる仕組み・全8回 第8回

――任せられるようになったあと、自分はどこに関わりたいか

AIに任せる仕組みを作って、最後に残った時間 — 「文明の夜明け」の先で考えること

AIと小説をつくる仕組みを紹介する、全8回連載の第8回です。

前回の 「AIに小説を書いてもらう手順を設計する — ハーネスと、書き直すループ」 では、執筆担当AIエージェントが書いた原稿を、複数の評価担当AIエージェントが読み、 その指摘を次の改稿へつなぐ仕組みを紹介しました。

作品の目的や人物を設定ファイルに書き、読む順番や役割分担をハーネスとして整え、 評価と改稿のループを回す。一年間、小説を書くために取り組んできたことです。

仕組みが動くようになったとき、私は、このやり方に納得しました。 毎回の指示だけで長い物語を書き続けてもらうより、判断の根拠と仕事の手順を残しておく。 それを複数のAIエージェントが参照しながら、原稿を受け渡していく。 自分が目指していた制作の形が、かなり見えてきました。

同時に、ひとつのことに気づきました。

この仕組みで、いちばん時間がかかるのは、
私が読むところなのではないか。

最終回は、設定ファイルの外に残った、この時間について考えます。

1.任せられるようになって、自分が止めていると分かった

原稿を作る速さと、読む速さ

AIエージェントは、設定を読み、原稿を書き、評価をまとめます。 私が改稿を依頼すると、指摘を踏まえた次の版が作られます。

もちろん、設定と食い違うこともあります。評価が高くても、自分にはしっくりこない文章もあります。 それでも、原稿を作り直す速度は、私が一つひとつ読んで考える速度を上回ります。

制作工程だけを見れば、私はボトルネックです。

原稿ができても、私が読まなければ先へ進めません。 どの指摘を受け入れるか。直したことで、人物の言葉が自然になったか。 この文章を、自分の作品として送り出したいか。そこで時間がかかります。

仕組みを整える前は、どうすればAIに書き続けてもらえるかを考えていました。 書き続けられるようになると、今度は、自分がどこで止めているのかが見えてきました。

小説では、その時間を残したかった

ただ、小説では、その時間をなくしたいとは思いませんでした。

自分が読んで面白いと思うことも、私が小説を書く理由だからです。 ルミや莉子が何を言い、何を言わなかったのか。その場面を読み、自分の中に何が残るのか。 それを確かめる時間まで省いてしまったら、私にとっての創作の楽しみも減ってしまいます。

評価の点数は参考になります。 でも、点数を見ただけでは、自分がその小説を読んだことにはなりません。

読者が面白いと感じるかどうかは、一人ひとりに委ねるしかありません。 その前に、私自身が読んで、この作品を送り出そうと思えるか。その判断は残しておきたいのです。

工程を速くするうえでは待ち時間でも、私にとっては、作品に関わるための時間でした。

2.サイト制作では、違う場所で確かめていた

「文明の夜明け」を感じた体験

小説と並行して、Digital Supporters Clubの会員制クラブサイトも作っています。 その過程で経験したことを、 「ものづくりの時間が変わった――『文明の夜明け』を感じた」 という記事に書きました。

会員ごとのフォルダ作成や権限設定を支援する、小さな管理ツールの開発です。

AIはコードを書くだけでなく、そのコードを確かめるテストも作り、実行しました。 問題があれば修正し、またテストする。 テストに使う模擬的なSharePointの環境まで、コードとして用意していました。

作る、試す、直す、もう一度試す。

この一連の作業が、自分の知っていたシステム開発とは違う速度で進んでいきました。

私はプログラムを一行も書いていません。 それでも、自分が必要としている道具が形になり、動作を確かめるところまで進んでいく。 その様子を目の前にして、文明の夜明けを感じました。

コードを全部読む代わりに、動かして確かめる

このとき、私は生成されたコードをすべて読むことはしませんでした。

設計書には目を通しました。自分が頼んだ内容になっているかを確認し、実際の環境で動かしました。 しかし、小説の原稿を読むときのように、一行ずつ表現を味わう読み方ではありません。

小説では、文章そのものを読みたい。 管理ツールでは、必要な仕事が意図したとおりに行われるかを確かめたい。

同じ私でも、何を作るかによって、判断を入れる場所が違っていました。

コードを全部読む工程を通らなくても、開発は進みます。そのぶん、AIが書いて試す速さを生かせます。 ただ、AIによるテストが通っても、実際に使う環境で動くかどうかは、別に確かめる必要がありました。

テストの中では合っていても、現実とは違った

実際、AIが用意したテストを通過したあと、本物の日本語版SharePointで問題が見つかりました。

コードは、権限の名前が英語で返ってくる前提で作られていました。テスト用の模擬環境も、同じ前提でした。 両方が英語の名前を使うので、テストは通ります。

ところが、本物の環境からは日本語の表示名が返ってきました。

コードとテストが一致していることと、
現実に合っていることは違っていたのです。

私は実行結果をAIへ返しました。AIは表示言語に左右されない方法へコードを修正し、テストも追加しました。

ここで私が行ったのは、コードを自分の手で直すことではありません。 実際に使う環境で確かめ、見つかった違いを制作の工程へ戻すことでした。

この経験は、小説を書く仕組みにもつながります。 原稿と設定が一致しているかは確認できます。 しかし、それを読んで何を感じるかは、実際に読んでみなければ分かりません。

3.速さを受け入れながら、どこに関わるかを決める

人間の判断を待たない工程は増えていく

この二つの経験から、私は、人間が途中で判断する機会は、 仕事によってはこれからも減っていくと思うようになりました。

一つの作業が終わるたびに人が読み、確認し、次へ進む許可を出す。 その時間を省ければ、成果物ができるまでの時間は短くなります。 速さが経済的な価値を持つ環境では、確認を自動化できないか、まとめて行えないかと考えるのは自然です。

対象を限った作業であれば、依頼してから成果物ができるまで、 一度も人が判断を挟まない形も増えていくでしょう。

私は、それ自体を悪いことだとは考えていません。

何度も繰り返す処理や、結果を機械的に確かめられる作業まで、必ず人が待ち構えている必要はないからです。 一方で、人の確認を外したからといって、品質が自動的に上がるわけでもありません。 SharePointの経験では、コードとテストに共通する前提が、現実と食い違っていました。

自分の設定ファイルにも、確かめていない根拠があった

小説の調査記録でも、同じような問題に向き合いました。 AIが調べた情報をファイルに残し、執筆や評価の根拠にしていましたが、 出典のURLがあるだけでは、原典を直接読んで確かめたのか、 要約や解説を経由したのかが分かりません。

そこで、調査記録の一行ごとに確度ラベルを付けました。 どこまで確かめたかを、四段階で残します。

ラベル どこまで確かめたか 本文での扱い
A 法令や公的機関の一次資料を、原典で直接確認した 数字や条文の断定に使える
B 公的機関の情報だが、要約や解説を経由している 事実の方向は使える。数字はAへ上げてから出す
C 二次情報(解説記事、事業者の見解、まとめ記事) 本文で断定に使わない
D 未確認 本文で断定しない

数字を本文へ出すときは、その行がAであることを確認します。 BやCであれば、先に原典へ当たってAへ上げてから使います。

2026年9月6日の導入時、その日に追加した調査記録には、Aの行が一つもありませんでした。 これは、記録がすべて誤りだったという意味ではありません。 原典で直接確かめたと言える行が、まだなかったのです。

本文と調査記録を照合して一致していても、調査記録そのものの根拠が確かとは限りません。 ラベルを付けても、それだけで正しくなるわけではありません。原典に戻って確認する作業が必要です。

コードとテストの照合にも、本文と調査記録の照合にも、共通する限界がありました。
同じ前提を共有したもの同士を比べるだけでは、その前提の誤りを見逃すことがあるのです。

脅威という言葉だけでは、付き合い方は決まらない

文章、プログラム、設計書、画像。 AIが作ったり、制作に関わったりするものは、身の回りで増えていくと思います。 公開されたインターネットの情報だけでなく、仕事で使う資料や、自分だけが使う道具にも、 その変化は広がるでしょう。

私は、その変化を脅威という言葉だけで捉えたくありません。

自分ではコードを書かなかった私が、必要な道具を作る工程に参加できました。 長い物語を作るために、複数のAIエージェントと原稿を受け渡すこともできるようになりました。 できることが増えた実感があります。

AIが文章やプログラムを作ることは、これから当たり前になっていくと思います。 その変化を受け入れ、AIに何を任せ、自分はどこに関わるのかを、暮らしや仕事の中で考えていきたいのです。

すべての工程を自分の手で行わなくてもいい。 途中の成果物をすべて読む必要も、仕事によってはないでしょう。 そのうえで、出来上がったものを誰が使うのか。実際に役に立っているのか。 問題が起きたときに、どこへ戻ればよいのか。

制作を速く進める仕組みと、その成果を実際に使って確かめる機会を、両方持っておきたいと思います。

経営に置き換えると

人がすべての成果物を確認することを前提にすると、AIが作る速度に確認が追いつかなくなるかもしれません。 そこで必要になるのは、業務ごとに、人が判断する場所を具体的に決めることだと思います。

社内で比較するための案なのか。顧客へそのまま送る文章なのか。 実行すれば権限や契約条件が変わる処理なのか。 同じ「AIが作ったもの」でも、確かめるべきことは違います。

今回の管理ツールでも、まず新しい会員一人の利用準備に範囲を絞りました。 実際に試し、運営が楽になるかを確かめるところから始めました。

任せる範囲を決め、結果を確かめ、その結果に応じて範囲を変える。 この判断まで含めて、AIと働く環境を作ることなのだと思います。

最後に残したい時間

第2回は、 「AIに長編小説を書かせ続けるために、設定ファイルを16個に分けた話」 でした。

その設定の置き場を今回あらためて数えると、直下に24ファイルと、 調査記録と作中の観測値を収める2つのフォルダがありました。 24ファイルの内訳は、番号の付いた22ファイルと、人物の確認用ファイル、文体の憲法です。 フォルダ内の記録は、この数には含めていません。

第2回のタイトルに置いた数字は、制作を続ける間に変わりました。

ファイルが増えたから、質が上がったとは言えません。 調査記録がそろっていても、原典の確認が足りていないことはありました。 書き残すべきことや、確かめるべきことが変わり、そのたびに構成を見直してきた結果です。

この連載では、設定ファイルの質を、別の日の自分と、担当の違うAIが、 同じ判断に行き着けることとして考えてきました。

作品の目的、人物の願い、文体、時系列。 それらを書き残し、AIエージェントが使える手順に組み込みました。 評価の観点を分け、指摘を改稿へ戻す流れも作りました。

その仕組みは、これからも変わるでしょう。 任せられることが増えれば、今は私が行っている確認を、AIに任せることもあると思います。

それでも、小説を読む時間は残したい。

AIエージェントが原稿を作る速さに、私が読んで考える速さは追いつきません。 でも、自分が読んで面白いと思うことも、私が小説を書く理由だからです。

サイト制作で感じた「文明の夜明け」は、ものを作る工程が、 自分の知っている速さを超えて動き始めた実感でした。 小説制作では、その速さの中で、自分が残したい時間に気づきました。

設定ファイルも、ハーネスも、評価と改稿のループも、AIに任せるために作りました。 その仕組みが動くようになったことで、今度は、自分がどこに関わりたいのかが見えてきました。

すべてを自分で作ることにこだわらなくなっても、 自分が何に価値を感じるのかは、問い続けていたいと思います。

「自分はどこに関わりたいか」という問いには、対応する一つの設定ファイルはありません。 仕組みを使いながら、私自身が考え続けることです。

前回: AIに小説を書いてもらう手順を設計する — ハーネスと、書き直すループ

次回: 全8回の連載は、今回で終わりです。