はじめに
生成AIとの会話そのものについて、最近あらためて考えています。
私は 2026/01 から、趣味で利用している個人契約の ChatGPT Plus を存分に使って、趣味のプログラミングをしています。ちなみに、現在がピークだとは思いますが、Plus 契約を4つ持っています。
その枠を使って、Codex + GPT-5.5 にプログラムをすごくたくさん書いてもらっています。かなりざっくりした仮の値ですが、2026/01 から 2026/04 までの4か月間で、おおよそ月に80時間ずつくらい、だからトータル320時間程度、Codex + GPT-5.x と会話しているように思っています。
生成AIは仕組み上、自然言語で応対できるようになっていて便利ですね。一方、OpenAI Codex + GPT-5.5 を使ってプログラミングしていると、これは単なる自然言語による会話というより、自然言語を用いたプログラミング作業になっているよ、という感覚を改めて強く思うようになってきています。。
ここで使っている自然言語は、私にとっての母国語である日本語です。このため、見た目には普通の日本語に見えます。でもですね、私が生成AIに向かって書いている文章は、たぶん日本人がふだん人間同士の会話で使っている日本語とは、異質なものなのだろうなぁ、という気がします。
生成AIに気持ちよく働いてもらうために、目的や制約や確認してほしいことを、かなり意識して言葉を注意しながら紡いでいるためです。そう、その手の界隈の人がいうところの、自然言語によるプログラミングですね。
自然言語プログラミングという感覚
ここで言っている「自然言語プログラミング」ですが、従来のプログラミング言語を単純に置き換えるものではありません。多分。
私の感覚では、自然言語で次のようなことを伝えながら、生成AIに作業してもらうことです。
- なにを求めているのか
- なにをどう変えたいのか
- どこまで省略してもコンテキストで補完して迷いなく作業進められるか
- どのような補助情報を与えたら迷いが消えるか
- それは生成AIにとって納得できる内容か
- 生成AIは気持ちよく作業できているか
これらは、従来のプログラミング言語の範疇とは一部(?)異なります。プログラム仕様だったり、開発プロセスの定義だったり、ゴール設定だったり、作業分割だったり、ソフトウェア開発の近傍だった内容ではありますが、プログラミング言語そのものとは違うものです。
しかし、生成AIにとってはかなり重要な入力です。
まあ、プログラミングという範疇ではなくって、ソフトウェア開発という大きなくくりで、ウォーターフォールだかアジャイルだかのエッセンスというかなんというか、を爆速にイテレーションできてしまい、それを自然言語で操るイメージかもしれません。
ということで、私が Codex と会話している日本語は、普通の会話とは似て非なるもの、なのでしょう。ちょっとした言葉遣いの選択ミスで、思わぬデメリットも導出しますものね。
理解というより、慣れ
たくさんの会話の積み重ねを経て、少なくとも GPT-5.x、特に Codex 系のものの考え方や言葉遣いとか癖が、少しずつ見えてきた気がします。（本当は延べ1000時間とか積んでから考えたいけれどね）
これは、生成AIとはどういうものかを理論的に理解している、という話ではありません。
どちらかというと、慣れの話です。
訓練というか、反復練習というか、そういうものに近い感覚があります。
同じような依頼を、少し言い方を変えながら何度も投げます。
返ってきた結果を見て、どこが伝わっていて、どこが伝わっていないのかを確認します。あるいは途中で停止ボタンを押します。
うまくいかなければ、制約や目的の書き方を少し変えて、また依頼します。
そういう往復を繰り返しているうちに、こちらの言葉の選択、順序、コンテキストの伝え方、なども少しずつ変わっていきます。
なお、なるべく気にしたくないのですが（気にしています）、その裏側では大量のトークンが溶けていきます。
総会話時間という指標
私たちの生成AI経験の習熟度合いの指標のひとつとして、総会話時間って大事なんじゃないかな、と思うようになってくる今日この頃です。
短いプロンプトを数回試すだけでも、便利さは分かります。
でも、何十時間も何百時間も同じ系統の作業を一緒に進めていると、それとは別の感覚が出てきます。
どのくらい具体的に言えば伝わるのか。
どこまで任せてよいのか。
どのタイミングで人間が止めたほうがよいのか。
どの言い方をすると、余計な方向へ広がりやすいのか。
そういうものは、世間の生成AIハウツー情報を読んだだけではなかなか身につかなくて、会話の往復の中で少しずつ体に入ってくるものなのかもしれません。多分、私にとってはネイティブではない英会話、この英会話を使って仕事を依頼する、とかとおんなじような文脈のものと思えてきます。
たまに、Codex 系の生成AIを飛行機の copilot、つまり副操縦士になぞらえる表現があります。
その比喩を借りるなら、飛行機のパイロットの世界では総飛行時間が一つの指標になる、と聞き及びます。
さらに、エアライン採用では 1500 時間前後が目安になる場合もある、と聞き及びます。国や制度によって違うのでしょうけれど、そう考えると、私はまだまだエアラインを飛べない相当の生成AI使用エンジニアなのですね。(仕事で生成AIを操作する時間が足されていない :-P)
もちろん、生成AIとの会話をそのまま操縦に重ねるというのは乱暴な話題ではあります。それでも、長い時間一緒に作業してみないと見えてこない感覚がある、という点では少し似ているのかもしれません。私も早く生成AIとの会話が10000時間超えの境地に至りたいものです。
GPT-5.x の進み方の癖
たくさん会話していると、GPT-5.x のプログラミング上の癖のようなものも見えてきます。
ここで言う癖は、生成されるコードの書き方の癖というよりも、問題をどう分解し、どの順番で考え、どのあたりに解決の糸口を見つけようとするか、というルートのようなものです。
同じ依頼をしても、人間のプログラマごとに最初に見る場所や、疑う箇所や、設計の切り方が少し違います。
それに近い意味で、GPT-5.x にも「こう進みがちだな」と感じる経路があります。まあ、これも生成AIという仕組みのうえで自然なことのようにも思えます。
たとえば、まず既存コードの周辺を読んでから小さく直すときもあれば、少し広めに構造を整理しようとするときもあります。設計情報をまとめようとすることもあれば、仕様検討しているのかなと思わせておきながらいきなり実装始めることもありますね。
テストを足す方向に進みやすい場面もありますし、逆に、人間が明示しないと境界条件の確認が薄くなる場面もあります。
このあたりは、まあ、数回の会話だけではなかなか見えてきませんし、それは仕方のないことだと思います。
長い時間、同じような開発作業を一緒に進めることで、少しずつ分かってくるものだと感じています。
人間同士の会話とは少し違う
ソフトウェア開発の現場においては、人間同士の会話では、かなり多くのことを省略できてきたことでしょう。
たとえば、長く一緒に作業している相手なら、「さっきの感じで」「いつもの形で」「ここは適当に」と言っても、ある程度は通じます。
しかし、生成AIとの会話では、このあたりの省略が思ったより危険です。
「適当に」は本当に適当になります。で困ったこと(?)に、適当にというのがすごく妥当なところをおさえてくることがあります。がたまにびっくりするような外し方もしてきます。
そして、「いい感じ」は、こちらが期待していない方向のいい感じになることがあります。ああ、でもね、生成AIが作業する都度、いいね、とか、よくないね、とかはちゃんと伝えることをお勧めします。いやこれだいじよ。
これは日本語ではありますが、人間相手のやわらかい会話とは少し違ったものとなってきます。
曖昧さを減らし、制約を明示し、作業範囲を区切り、作業の進め方を緩く制御し(TODO.mdを多用します)、そして確認観点を渡すための日本語です。
見た目はなんとなく普通にみえる文章でも、中身はかなり生成AIを意識した内容に寄っています。
小さいウォーターフォールを爆速で回す
Codex + GPT-5.5 を使っていると、実装そのものを手で書く時間は減ります。というか趣味ソフト開発だとソースコードは全く書いていません。それどころか設計の Markdown も原則手で書きません。というか横から書き換えると生成AIが混乱して作業の質が下がります。
私の場合、すごく小さいウォーターフォールを爆速でイテレーションしています。ああ、それはアジャイルが求めていた究極形態のひとつかもしれません。
まず大きいレベルから設計して Markdown を生成AIに書いてもらいます。それをもとに、より詳細化された Markdown を生成AIに書いてもらいます。
実装に入れるくらい Markdown が準備できたら、実装をしてもらいます。もちろん生成AIに。
実装の過程で生成AIが勝手に自動テストも足していきます。というか生成AIを観察していると、自動テストがあるからこそ生成AIのプログラミングの効率が上がっているのだと思います。
よく使う言い方
私が最近よく使っている言い方には、いくつかの型があります。
たとえば、調査から始めたいときは次のように言います。
README.mdと関連mdを読んでください。今回は仕様検討までです。
少し仕様を前に進めたいときは、検討結果の置き場所もあわせて指定します。
XXXについて仕様を検討して詳細化してください。作業結果については YYY.md に格納してください。
さらに実装へ進める前には、作業内容を TODO.md に落としてもらいます。
検討後の仕様を実装するにあたり、先に TODO.md に作業内容を追加してください。
逆に、もう進めてほしいときは次のように言います。
今までの会話の内容、そして TODO.md の内容にしたがって、実際の作業を進めてください。
こういう言葉は、日常会話としては違和感あります。
しかし、生成AIと作業するときには、これくらいの書きっぷりがちょうどよいことがあります。
生成AIに任せる部分と、人間が持つ部分
私の場合、Codex + GPT-5.5 にかなり多くのことを任せています。たとえば、ソースコードの実装、テストの追加、Markdown 文書の整理、README の更新、記事下書きの構成整理などです。まあ、下手にソースコードや設計 Markdown を変更してしまうと、生成AIが悩むという背景があります。
一方で、全部を任せているわけではありません。
- エンジニア観点で違和感のあるところはないか
- そのままの方針で、最終的に適切に動作しそうか
- 全体として辻褄合っているか
- 自分の期待する方式になっているか
こういう判断は、やはり人間側に残ります。
生成AIは非常に強力ですが、こちらが何を思っているのかを自然に理解してくれるわけではありません。
だから、コンテキストの近い人間同士なら自然にわかってもらえそうなこと、それを積極的に言語化をこころみて、それをプロンプトで伝えて、その結果が渡した伝えたかったことと一致するかどうかをチェックしています。
こういう判断の言語化とその結果フィードバックの観察こそが、人間側の大事な仕事になってきている気がします。
便利だが、雑にはできない
自然言語でプログラミングできるようになると、とても便利です。
ただし、自然言語だから雑でよい、ということではありません。
むしろ、雑な自然言語は、そのまま雑な作業結果につながります。
「全部いい感じにして」と言えば、AIは頑張ってくれます。
でも、その「いい感じ」が自分の期待と一致するとは限りません。一般的にコモンセンスなものは自動でも良い感じになるものの、そうでない場合は期待と違うものになりがちです。
そのため、生成AIとの作業では、自然言語の精度がそのまま開発品質に影響する場面があります。
これは、プロンプト職人になるべき、という話ではありません。
私の感覚では、もっと普通のことです。
私の頭の中のイメージと、生成AIが考えていることのギャップを埋めるように、発話して、回答に傾聴して、の繰り返しです。
その積み重ねです。
トークン単価が割安なうちに
一方で、少し心配していることもあります。
クラウド生成AI各社で、トークン使用や高性能モデル利用のコストが上がっていく傾向がある、というニュースも耳にします。
このあたりは個別のサービスや時期によって事情が違うので、雑に断定することはできません。
ただ、もし高性能な生成AIとの長時間の会話がだんだん高価になっていくなら、これから始める人たちは「総会話時間」を稼ぎにくくなるかもしれません。
生成AIとの作業に慣れるには、説明を読むだけではどうしても身につかない部分があります。
実際に依頼して、失敗して、言い方を変えて、また試す。
その反復の中で、ようやく分かってくる感覚があります。
なので、今のところ比較的割安に使えているトークン単価の間に、どれだけ会話して、どれだけ生成AI駆動のソフトウェア開発を体験しておくのかが大事なのではないか、と感じています。
これは、焦って使い倒せばよい、という話ではありません。といいつつ、私焦って使っているかも (苦笑)
なんにせよ、生成AIとの開発は、実際に長時間やってみないと分からないことが多いです。
どのように頼むと実装が進むのか。
どのくらい仕様を書けばよいのか。
どこで人間が止めるべきなのか。
どのタイミングでテストや文書を整えるとよいのか。
どのタイミングで git リポジトリと同期すればよいのか。
そういう感覚を得るためにも、私は今、かなり頑張ってアプリを書いてもらっています。（頑張るのは生成AIだけれどね）
まとめ
Codex + GPT-5.5 と長く会話していると、自然言語でプログラミングしている感覚がかなり強くなってきました。
使っている言語は日本語です。
しかし、それは人間同士の日常会話そのものではありません。
仕様を検討し、Markdown に落とし、TODO.md で作業を区切り、実装してもらい、結果を観察して、また言い方を変える。そういう小さいウォーターフォールのようなものを、自然言語で爆速に回している感覚があります。
このとき人間側に残る仕事は、単に命令を書くことだけではありません。自分の頭の中のイメージと、生成AIが進めようとしていることのギャップを見て、必要なコンテキストを足し、結果フィードバックを観察することです。
そして、その言葉の使い方は、知識として一度読めば身につくものというより、総会話時間の中で少しずつ慣れていくものだと感じています。たくさん会話して、たくさん失敗して、たくさんトークンを溶かして、ようやく少しずつ見えてくるものがあります。
生成AIがコードを書いてくれるようになるほど、人間の仕事はなくなるのではなく、意図や判断を言語化し、その結果を見てまた調整する方向に寄っていくのだと思います。作業をしている時間がとても圧縮され、その代わりに考える時間が増えるって感じです。
最近人に指摘されて気づいたのですが、私の書くものや私の発話が、生成AIのそれとすごく似てきたらしい。。。それって,,,