OpenAI Codexで
「人工無能」チャットボットを作ってみた

OpenAI Codexを使って、簡易的なチャットボットを作ってみました。いわゆる「人工無能」と呼ばれる、パターンマッチング型の会話システムです。

最近の生成AIのように複雑な仕組みではなく、学習データからパターンを抽出して応答を返すシンプルなものです。今回は「ハイブリッド会話エンジン」という名前をつけて開発しました。

昔ながらのチャットボットを、AIツールで作るとどうなるのか。その過程で感じた、AIとの協働開発の可能性と難しさについて書いていきます。

関連記事

1. プロジェクトの準備

1.1. 開発環境の確認

まず、プロジェクトフォルダでOpenAI Codexを立ち上げました1。画面には利用状況が表示されています。

コンテクストは100%残っており、まだ何も作業していない状態です。コンテクストとは、AIがプロジェクトの内部情報をどれだけ「記憶」できるかを示す指標のようなものです。ここでは、どれだけの情報を頭の中に入れておけるか、という意味だと考えてください。

5時間制限も100%近く残っています。この段階では、まだ何も消費していません。

1.2. 仕様書の準備

事前に作成しておいた仕様書を用意しました。ゼロから指示を出すのではなく、ある程度の叩き台があった方がスムーズに進められると考えたからです。

今回のチャットボットには、以下の要件を設定しました。

  • ターミナルで動作するコマンドライン型のツール
  • TSV形式(タブ区切り)で会話データを管理
  • 終了コマンドは「exit」
  • 形態素解析ライブラリを使用
  • ハイブリッド型の応答生成エンジン

形態素解析とは、文章を意味のある最小単位(形態素)に分割する技術です。たとえば「今日は晴れです」を「今日/は/晴れ/です」のように分けることで、コンピュータが文章を理解しやすくなります2

2. Codexへの指示出し

2.1. 初回の指示

画面に向かって、自然な日本語で指示を出していきました。

まず、仕様書の内容を伝えます。次に、ターミナルで動作するものにしてほしいと伝えました。さらに、コマンドラインツールとして動作し、会話データをTSV形式で管理すること、形態素解析にはMeCabを使うことなどを順番に指示していきました。

指示を出すと、Codexが処理を始めます。

画面中央のファイル一覧がピカッと光りました。これは、新しいファイルが作られたときの合図です。Codexが自動的にファイルを生成していく様子が、リアルタイムで確認できます。

ファイル一覧はwatchコマンドとtreeコマンドを使って、1秒ごとに自動更新するようにしていました。普段見る必要はありませんが、AIがどのようにファイルを作っているのか観察するには便利です。

2.2. 生成されたファイルの確認

ファイル検索で、どんなコードが生成されているのか覗いてみました。

markov.pybuild.pyといったPythonファイルが作られています。中を見ると、クラスや関数がきちんと定義されていました。マルコフ連鎖という手法を使った、会話生成の仕組みのようです。

マルコフ連鎖とは、過去の状態だけを見て次の状態を決める確率的な手法です3。チャットボットの場合、「こんにちは」の次には「元気ですか」が来やすい、といったパターンを学習して応答を生成します。

関数があり、クラスがあり、それらが部品として組み合わさっています。

しばらくすると、Codexから結果が返ってきました。「次のステップは、まずインストールしてから確認しなさい」とのこと。なるほど、パッケージのインストールが必要なようです。

3. 環境構築との格闘

3.1. パッケージのインストール

ターミナルを開いて、指示されたコマンドを実行します。

pip installでパッケージをインストールしようとしたところ、エラーが出ました。コマンドが見つからないと言われます。そもそもpipがインストールされていないようです。

普段使っているパソコンではなく、古いパソコンにLinuxを入れて、そこにSSHで接続して作業していました。そのため、必要なパッケージが揃っていなかったのです。

3.2. 仮想環境の作成

次に仮想環境を作ろうとしました。

Pythonの仮想環境とは、プロジェクトごとに独立した環境を作る仕組みです4。たとえば、プロジェクトAではバージョン3.8、プロジェクトBではバージョン3.10を使う、といったことができます。

しかし、ここでも問題が発生しました。「仮想環境が作成されませんでした。ensurepipが利用できません」というエラーです。

Python本体のインストール時に、pipを含めるオプションを指定していなかったのが原因でした。

3.3. 必要なパッケージの追加インストール

結局、Python関連のパッケージを追加でインストールすることにしました。

python3-pippython3-venvといったパッケージを、Linuxのパッケージマネージャーでインストールしていきます。これらがあって初めて、仮想環境が使えるようになります。

基本的に、AIが操作した時にパソコンの中身がぐちゃぐちゃになるかもしれないと思って、古いパソコンを使っていました。必要に応じてパッケージをインストールするやり方は、何度も通る道なので覚えておくと良さそうです。

やっと必要なパッケージが揃いました。

3.4. コマンドとしての実行準備

仕様では、コマンドライン型のツールにすることになっていました。つまり、chatbotのようなコマンド一つで起動できるようにしたいわけです。

ただ、コマンドにしないで直接Pythonスクリプトを実行した方が早かったかもしれません。それでも、せっかくなのでコマンドとして実行できる形にすることにしました。

生成されたファイルを見ると、main.pyを実行すれば動きそうです。

データファイルのconversation.tsvを確認すると、サイズは5.4KBでした。少し少ない気がしますが、まずはこれで試してみます。

コード自体は、エンジン部分が大きめですが、他はそれほどでもありません。全体的に、まだ小規模なプログラムです。

4. 初回実行と動作確認

4.1. チャットボットの起動

準備が整ったので、いよいよ実行してみます。

コマンドを叩くと、無事に起動しました。プロンプトが表示されて、入力待ちの状態になっています。

4.2. 会話のテスト

試しに「こんにちは」と入力してみました。

すると、何か変な応答が返ってきました。「する予定あなた」と表示されています。意味が通じません。

次に「予定はそろそろ」と入力すると、「私も」と返ってきました。

何度かやり取りをすると、なんとなくそれっぽい雰囲気は出ています。完全に意味不明というわけではありませんが、ちゃんとした会話にはなっていません。

最初の応答は意味が分かりませんでしたが、それでも、なんとなくそれっぽい感じで動作していました。

一応、最低限の動作は確認できました。

4.3. 終了コマンドの確認

「exit」と入力すると、ちゃんとプログラムが終了しました。仕様通りに動いています。

ここまでの状態を、一旦Gitリポジトリに保存しておきました。もし後で問題が起きても、この時点に戻せるようにするためです。

5. 改善の試み

5.1. 会話データの拡張

Codexに対して、会話データをもっと大量に増やすよう指示しました。

データが少なければ、応答のバリエーションも少なくなります。もっと多様な応答ができるよう、データ量を増やしたいと考えたのです。

Codexが処理を始めます。しばらく待つ間、再度チャットボットで遊んでみることにしました。

5.2. 2回目の動作テスト

もう一度起動して、「こんにちは」と入力します。

今度は「予定」という単語を返してきました。さっきと似たような応答です。

「元気ですか?」と聞いてみると、「元気です」と返ってきました。今度は少しマシです。

「はい、ありがとう」と続けると、応答が少し変わりました。データが増えたことで、わずかに改善されているようです。

「音楽」と入力すると、疑問符が返ってきました。単語だけを入力すると、はてなマークで返すパターンがあるようです。

「元気です」と言うと、また「元気です」と返してきます。このあたりは、明らかにパターンマッチングの限界です。

微妙に合っているような、合っていないような、この「通じない感じ」がチャットボットの面白いところです。今の生成AIは、もっときちんとした応答をしますが、昔はこういった、なんとなく言葉の断片が対応したようなものがよく使われていました。

5.3. データ構造の確認

データファイルconversation.tsvの中身を見てみました。

キーワードと文章がペアになって並んでいます。つまり、入力されたキーワードに対して、あらかじめ用意された応答パターンから選んで返す仕組みです。

これだと、応答パターンをたくさん作らないと、多様な会話に対応できません。パターンに該当しない入力には、うまく反応できないということです。

そこで、もう一度Codexに指示を出しました。もっと自然な会話ができるように改善してほしい、と。

5.4. エンジンの改善提案

Codexから、いくつかの提案が返ってきました。

  • 検索強化の仕組み
  • 文脈を考慮したランキング
  • 類似度評価の改善

これらを実装してみることにしました5。設定を変更して、再度実行します。

6. システムの仕組みを探る

6.1. 動作原理の質問

せっかくなので、このチャットボット自身に質問してみることにしました。

「このプログラムはどのような仕組みで動作していますか?簡単に分かりやすく説明してください」

すると、チャットボットが答えてきました。

入力文を形態素解析して重要な単語を取り出す。次に、データから似たような発言を検索し、その返答を候補にする。さらに精度を高めるため、類似度を自動評価する。返答データから新しい文を生成して候補に追加する。近い話題だけで作る局所的なモデルも使う。全ての候補にスコアをつけて、最も良いものを返す。

なるほど。思ったより複雑な処理をしていました。

単純なパターンマッチングだけではなく、類似度を計算したり、候補をランク付けしたりしているようです。

6.2. 生成コードの確認

engine.pyの中身を見てみました。

HybridEngineというクラスが定義されていて、複数の手法を組み合わせているようです。コメントはあまり入っていませんが、関数名から処理の流れは推測できます。

こんなに複雑なコードが、それなりにちゃんと動いているということ自体が驚きです。Codexが指示だけで、ここまで作ってくれたわけですから。

7. リソース使用状況の確認

この時点で、コンテクストの使用状況を確認してみました6

94%が残っています。つまり、全体のコンテクストのうち、まだ6%しか使っていません。まだまだ余裕があります。

5時間制限の方も、93%残っています。7%を使った計算です。

30分ほど作業して、これだけしか消費していません。ペースとしては、かなりゆっくりです。もちろん、もっと集中して作業すれば、どんどん消費されていくでしょう。それでも、この程度のペースでポチポチと作っていくことは十分可能だと分かりました。

8. AIとの協働開発で見えた課題

8.1. コード修正の難しさ

実際に使ってみて、いくつかの問題点が見えてきました。

まず、こうやって簡単にコードができてしまうと、いちいち修正するよりも、また一から作り直した方が早いと感じることがあります7

たとえば、人間がコードをちょこちょこ修正しても、次にAIが変更を加える過程で、ガサッと全体が書き換わってしまうことがあるのです。

8.2. 分業の難しさ

プログラムの90%をAIに作らせて、残りの10%を人間が作る。そういう分業を考えたとします。

しかし、機能を改善するために再びAIを使うと、せっかく人間が苦労して読み込んで直した10%の部分が、やり直しになってしまいます。これは、なかなかやるせない状況です。

結局、人間とAIが協調してコードを書くというのは、思ったより難しいのかもしれません。

8.3. うまくいきそうな分業

とはいえ、うまくいくパターンもあります。

設計やアーキテクチャを人間が考えて、実際のコードを書くのはAIに任せる。こういう分業なら、成り立ちそうです。

書いたコードそのものをいじるのは難しいですが、大枠を決めるのは人間、実装はAI、という役割分担なら機能します。

8.4. コードの複雑化

ただ、コードの量が増えてくると、AIもぐちゃぐちゃなことをし始めます。

そうなると修正が難しくなります。これは、プログラム開発では常に起こることです。仕組みが複雑になればなるほど、どこかで破綻がやってきます。

その破綻を、人間の力だけでは制御できなくなることがあります。AIに任せていれば、AIの性能が上がった時に、また超えられるかもしれません。簡単に起こりうる話です。

大きなプログラムを維持していくのは、AIがあろうとなかろうと、なかなか難しいものです。

9. チャットボットと生成AIの違い

9.1. 「それっぽさ」の正体

このチャットボットとの会話を振り返ってみると、面白いことに気づきます。

向こうは適当なことを言っているのに、こちらが意図を汲んであげることで、会話らしく成立しているように見えるのです8

でも、今使っている生成AIも、実はこの延長上にあるのかもしれない。そう思うと、不思議な気持ちになります。

9.2. 仕組みの共通点と違い

心にもないことがめちゃくちゃに書かれてくる。それが、このチャットボットの仕組みです。

いろんな考え方を組み合わせて、言葉を分解したり組み合わせたりして作っています。これは、生成AIの延長上にあるわけではありません。技術的には、いくつかの飛躍があります。

それでも、当初の考え方はすごく似ています。入力された文章や学習したデータから、言葉のパターンを見つけ出す。その部分は、共通しているのです9

9.3. 会話データの課題

作業を進める中で、会話データの作り方に問題があると気づきました。

単純に文章がペアになっているだけでは、柔軟な会話は難しい。もっと工夫が必要です。

そこで、Codexに再度指示を出しました。会話データの構造を改善してほしい、と。

10. 開発の実際

10.1. 反復的な改善プロセス

こんな風に、開発は気づいたことをちょこちょこ言って、それをまた反映させる、という流れが延々と続いていきます。

もっとしっかりとしたやり方もあると思います。最初に完璧な設計を作って、それに従って実装する、というような。

でも、ざっくりとこのような形でプログラムが作れるようになっている。そのこと自体が、面白いと感じます。

10.2. Codexの特徴

Codexを使っていて気づいたのは、文章がすごく短くまとまっていることです10

一般的な生成AI、たとえばChatGPTをそのまま使っている時と比べると、簡潔です。これは、これで良い特徴だと思います。

長々とした説明ではなく、要点を押さえた短い応答。それが、作業のテンポを保つのに役立ちました。

11. 完成したチャットボットの評価

11.1. できたこと

最終的に、一応動作するチャットボットができました。

完璧ではありませんが、入力に対して何らかの応答を返します。時々、意味が通じない応答もありますが、それもご愛嬌です。

形態素解析を使い、マルコフ連鎖やパターンマッチングを組み合わせた「ハイブリッド会話エンジン」。仕様書に書いた要件は、一通り満たしています。

11.2. できなかったこと

しかし、自然な会話には程遠い状態です。

応答の多くは、データに含まれるパターンの組み合わせです。文脈を理解して答えているわけではありません。

人間が意図を汲んであげることで、なんとなく会話が成立しているように見えるだけです。

会話データの質と量が、そのまま性能に直結します。今回は限られたデータだったため、応答のバリエーションも限られていました。

12. おわりに

OpenAI Codexを使って、簡易的なチャットボットを作る過程を体験しました。

指示を出すだけで、それなりに動くコードが生成される。環境構築でつまずくこともありましたが、最終的には動作するものができました。

ただ、AIとの協働開発には、まだ課題も多いと感じます。人間が修正した部分が、AIの次の変更で上書きされてしまう。コードが複雑になると、制御が難しくなる。

それでも、設計を人間が担当し、実装をAIに任せるという分業なら、十分に実用的です。

そして何より、昔ながらの「人工無能」を、最新のツールで作ってみるという体験そのものが、興味深いものでした。生成AIの原点を垣間見たような気がします。

  1. 本記事で使用したのはOpenAI Codex CLIです。これは2025年4月に発表され、同年5月に一般公開されたオープンソースのターミナルベースコーディングツールで、Rustで実装されています。旧来のOpenAI Codex APIとは異なる製品です。 – Codex CLI – OpenAI Developer Platform
  2. 形態素解析では、単語を分割するだけでなく品詞情報(名詞、動詞、助詞など)も付与されます。日本語の場合、助詞の扱いや複合語の処理が特に重要で、チャットボットの応答品質に大きく影響します。 – 人工無脳は考える – マルコフ連鎖による文生成
  3. マルコフ連鎖の正確な定義は「現在の状態のみ」で次の状態が決定され、過去の状態とは無関係である(マルコフ性)という特性を持つ確率過程です。記事中の「過去の状態だけを見て」という表現は不正確で、正しくは「現在の状態のみを見て」です。 – マルコフ連鎖 – Wikipedia
  4. Python仮想環境は、異なるプロジェクト間でのパッケージ依存関係の競合を避けるための仕組みです。venvモジュール(Python 3.3以降標準装備)やvirtualenvを使用して作成でき、プロジェクトごとに異なるPythonバージョンやライブラリバージョンを管理できます。
  5. これらは情報検索(IR)や自然言語処理(NLP)における一般的な手法です。類似度評価では、コサイン類似度やTF-IDF、文脈を考慮したランキングでは単語の出現位置や頻度を重み付けする手法が用いられます。
  6. Codex CLIのコンテクストは、ChatGPTのプランによって異なります。Plus、Pro、Business、Edu、Enterpriseプランに含まれ、プランごとに利用可能なメッセージ数や時間制限が設定されています。 – Introducing Codex | OpenAI
  7. 実際のCodex CLIには、この問題に対処するための機能が実装されています。承認モード(read-only/auto/full-access)で変更を制御でき、チェックポイント機能により任意の時点に巻き戻すことが可能です。また、差分表示機能により変更内容を確認してから適用できます。 – Enabling Claude Code to work more autonomously
  8. この現象は「イライザ効果(ELIZA effect)」として知られています。1966年にジョセフ・ワイゼンバウムが開発したELIZAという初期のチャットボット(パターンマッチング型)に対して、人間が感情や意識を持っているかのように感じてしまう心理効果です。「人工無能」という用語の起源でもあります。 – ELIZA – Wikipedia
  9. パターンマッチング型チャットボットと現代の生成AI(LLM)との間には、技術的な大きな飛躍があります。LLMはTransformerアーキテクチャとニューラルネットワークを使用し、単なるパターン照合ではなく、文脈理解と確率的な次単語予測により文章を生成します。両者の間には、統計的言語モデル、リカレントニューラルネットワーク(RNN)など、複数の技術的ステップが存在します。 – OpenAI for Developers in 2025
  10. Codex CLIは、対話型のターミナルインターフェースで動作し、開発者向けに簡潔な応答を返すよう最適化されています。デフォルトモデルはgpt-5.3-codex(2026年1月時点)で、コード生成、レビュー、リポジトリ規模の推論に特化しています。 – Codex Models – OpenAI Developer Platform