AI支援によるテクニカルライティング：どこで止めるか

C++のコードメンテナンス中、著者はコメントがどんどん長くなり、最終的には説明対象のコードよりも長くなってしまったことに気づきました。コメントをコードから完全に取り除くため、Claude.aiを使ってそのコメントをブログ記事に変換するという、現代的な方法を取ることにしました。これで終わりだと思っていましたが、事態は予想外の展開を見せました。

著者は草稿をGoogle Geminiにレビューしてもらいました。すると、実際の技術的エラーが発見されました。スタイル上の些細な問題ではなく、本物のプログラミングミスでした。Geminiは修正案を提案しましたが、実際に試してみるとコンパイルできませんでした。つまり、著者がコードレビューで長い間自信を持って主張していた元のコメントが間違っていたのです。誰もその反例を実際にコンパイルしようとしなかったため、誰も気づきませんでした。

そこで記事を白紙から書き直しました。その後、Perplexity.ai、ChatGPT、Microsoft Copilotなど、さらに多くのAIにそのバージョンを見せたところ、記事は収拾がつかなくなりました。各AIが前のバージョンで微妙に間違っていた点や考慮されていなかった点を次々と指摘しました。区別する必要があることが判明したもののために新しい用語が作られました。実行時特性のために意図的に選んだショートカットを「チェック済み」とマークできるように、ホワイトリスト機構が追加されました。最終的に、記事はコメントからブログ記事へ、そして実験ノートのようなものへと変貌しました。

著者は、このプロセスで最も書き留める価値があるのは、意見の相違にはまったく異なる2つのタイプがあり、その違いに気づかないまま深みにはまってしまったことだと考えています。最初のタイプには審判がいました。AIが「もっと良いアイデアがある」と言ってきて、実際にはそうでなかった場合、コンパイラが約10秒で議論を解決しました。誰も説得される必要はなく、コードがコンパイルされて正しく動作するかどうかだけが問題でした。このプロセスにおけるすべての技術的な論争は、どのAIがより自信があるかではなく、実際に確認することで解決されました。

2番目のタイプには審判がいませんでした。技術的な内容が固まった後、著者は記事自体について意見を求めましたが、意見は真っ二つに分かれました。ChatGPTやCopilotなどの一部のモデルは長すぎると考えました（結局、AIはよく要約を求められます）。Claude.aiは、修正された結論を断言するだけでなく、間違いが起こる過程を示すことで、長さが価値を生んでいると考えました。長さについてコンパイルして答えを出すことは誰にもできません。「このポインタが破損するかどうか」というような客観的な真実が存在しないからです。それは事実の問題ではなく、記事の目的に関する問題です。意見が飛び交い始める前に、誰も（著者も含めて）その目的を明確にしていなかったことが判明しました。

膠着状態を打破したのは、さらなる議論ではなく、そもそも何を達成しようとしていたのかを振り返ることでした。著者は一般的な読者に簡潔さで評価される文章を書こうとしていたのではなく、コメントからリンクできるもの、将来そのファイルを開いてなぜそのようにキャストが書かれているのか疑問に思う一人の人のために書こうとしていたのです。それが明確になると、長さに関する議論のほとんどは自然に解消されました。一部は残りました。「長すぎる」という批判の中には、長さではなく、命名する必要のないものに名前を付けているという、それ自体正しい指摘がありました。それらの部分は著者が保持しました。

著者が考える一般化可能な教訓は、意見の相違が技術的なものか編集的なものかを判断できない場合、その混乱自体に立ち止まって名前を付ける価値があるということです。なぜなら、両者はまったく異なるツールで解決する必要があるからです。一方にはコンパイラ、実験、または事実が必要です。もう一方には、自分が実際に何をしようとしているのかを声に出して言うことが必要です。これは、会話の全員（人間もAIも）が、何のために最適化しているのかを確認する前に最適化に飛びついてしまうと、奇妙なほど簡単にスキップされてしまいます。

「これで完了」にコンパイラはありません。ある時点で、あなたが決断して次に進むしかありません。したがって、技術的な正確性が合意に達した後、キャストに関する記事の改訂は、著者（人間）が決めたところで止まりました。長すぎて結果を要約する必要があると思うなら、AIに聞いてみてください。🤖

この記事を改善するアイデアがあれば、GitHubでIssueを提出（さらに良いのはプルリクエスト）してください！