Codexで会計API連携は危険？Claudeで修正して学んだAI使い分け術

最近、日々の面倒な経理作業を少しでも楽にしようと思って、AIを使って会計ソフトと連携するちょっとしたツールを作ってみようと思い立ったんです。freeeやマネーフォワードといったクラウド会計サービスのAPIを使えば、色々なことが自動化できそうじゃないですか。

「今の時代、コードはAIに書いてもらえばできるかな」と、意気揚々と普段から使い慣れているChatGPT Plusに付属する(Codex CLI 5.3版) に頼んで開発をスタートしました。ところが、これがまさか泥沼の始まりだったとは…。今回は、僕が体験したAIコーディングの失敗と、そこから学んだ「AIツールの正しい使い分け」について、素人目線で正直に書いてみようと思います。

※前提としてChatGPT Proではないし、Codexも APIから使っているわけではないので$20ぐらいのChatGPT Plusの限界なのかもしれません。その前提で記事を見てもらえると。

Codex CLIで始めたAPI連携開発の落とし穴

最初は順調そうに見えました。Codex CLIは僕のざっくりとした指示に対して、ものすごいスピードでPythonのコードを生成してくれます。「さすが」と感動すら覚えましたね。

しかし、いざ生成されたコードを実行してみると、エラーではないけど、単純な回答しか答えてくれない。。。２０２４年での合算、２０２６年の合算など合算と年単位のみ、もっと自由な質問に会計相談してくれるAIを、、、最初は僕の環境設定が悪いのかと思ったんですが、よくよく調べてみると、そうではありませんでした。

自信満々に嘘をつく「ハルシネーション」の恐怖

最大の問題は、Codex CLIが時々見せる「自信満々の嘘」でした。専門用語でハルシネーション（幻覚）と呼ばれる現象らしいですね。

例えば、特定の会計データを取得するためのメソッドを書いてくれたんですが、APIの公式ドキュメントをいくら探してもそんなメソッドは存在しないんです。Codex CLIは、過去の膨大な学習データから「それっぽい」コードを生成するのは得意ですが、特定のサービスの最新かつ厳密な仕様を常に把握しているわけではありません。

特にOAuth 2.0のような複雑な認証フローや、マイナーなエンドポイントの仕様となると、存在しないパラメータを平気ででっち上げることがありました。しかも、すごくもっともらしい顔（テキストですが）で提示してくるので、素人の僕はすっかり信じ込んでしまい、デバッグに膨大な時間を溶かしてしまったんです。

会計APIの複雑さとAIの限界

会計APIというのは、一般的なWeb APIに比べてデータ構造が非常に複雑みたいです。勘定科目、税区分、取引先といったデータが相互に依存し合っていて、一つでも間違った形式でデータを送るとエラーになりますし、最悪の場合、間違った会計処理を引き起こしかねません。

汎用的なAIであるCodex CLIにとって、こうした「絶対に間違えられない厳密なルール」に基づいたコーディングは、少し荷が重かったのかもしれません。「だいたい合ってる」では済まされない世界ですからね。

Claudeで対応！驚異の文脈理解力

「もう自力で書くしかないか…」と諦めかけていた時、開発者のコミュニティで「複雑なタスクならClaudeの方がいいよ」という噂を耳にしました。Anthropic社が開発しているAIモデルですね。半信半疑で試してみることにしました。

20万トークンのコンテキストウィンドウが世界を変えた

Claude（特にClaude 3.5 Sonnetなど）の最大の特徴は、一度に処理できる情報量、いわゆるコンテキストウィンドウが非常に大きいことです。その数はなんと200,000トークン。これは書籍数冊分に相当する情報量らしいです。

この特徴を活かして、僕は対象の会計APIの公式ドキュメント（結構な長文です）をまるごとコピーして、Claudeに「この仕様書に基づいてコードを書いて」と指示してみました。すると、どうでしょう。Codex CLIがあんなに苦戦していた認証部分やデータ構造の定義を、Claudeはドキュメントの内容を忠実に守って、ほぼ一発で動くレベルのコードを生成してくれたんです。

「動かないコード」を的確に修正する能力

さらに感動したのは、バグ修正能力です。Codexが生成した「動かないコード」とエラーログ、そして正しいAPIドキュメントをセットでClaudeに渡して、「どこが間違っているか教えて」と聞いてみました。

Claudeはまるで熟練のプログラマーのように、「ドキュメントのこの部分の記述によると、パラメータ名は ‘xxx’ ではなく ‘yyy’ が正しいです。また、このデータは配列で渡す必要があります」といった具合に、具体的な根拠を示しながら的確に修正案を出してくれました。指示への忠実度と、与えられた文脈を理解する力においては、Claudeの方が一枚上手だと感じた瞬間でした。

結論！AIツールの正しい使い分け戦略

今回の痛い経験を通じて、僕は「AIは万能な魔法使いではない」という当たり前の事実を再認識しました。それぞれのツールには得意・不得意があり、それを理解して適材適所で使い分けることが、開発を成功させるカギになりそうです。

適材適所でツールを切り替えるのが現代流

僕なりにたどり着いた使い分けの結論はこんな感じです。

まず、ゼロからのアイデア出しや、一般的なアルゴリズム、有名なライブラリを使った単純な処理などは、圧倒的に高速なCodex が便利です。壁打ち相手としても優秀ですね。

一方で、今回の会計API連携のように、厳密な外部仕様が存在し、ハルシネーションが許されないタスクには、APIドキュメントの仕様書をしっかり読み込ませて作成が必要で、その部分の正確性でClaudeに任せるのが確実でした。既存コードのバグ修正やリファクタリングもClaudeの方が得意な印象を持ちました。

この先どうなる？将来展望

AI開発は「指示する力」が問われる時代へ

今後、AIのコーディング能力はさらに向上していくでしょう。そうなると、人間側の役割は「コードを書くこと」から、「AIに何をさせるかを正確に定義すること」へとシフトしていくはずです。

特に会計のような専門領域では、AIに丸投げするのではなく、「どのような会計処理が正しいか」というドキュメントや要件を人間がしっかり用意し、それをAIに理解させて監督する能力が問われるようになるんじゃないでしょうか。プログラミングスキルよりも、業務知識とAIへの指示力（プロンプトエンジニアリング力）が重要になる未来が見えます。

他分野への応用アイデア

今回の「厳密な仕様はClaudeに任せる」という知見は、他の分野でも応用できそうです。

Web制作：複雑なCMS構築

例えば、WordPressなどのCMSで複雑な独自テーマやプラグインを開発するシーン。WordPressのコアな関数やフックの仕様は膨大で複雑です。公式のコーディング規約やドキュメントをClaudeに読み込ませることで、規約に沿った安全で保守性の高いコードを生成させる、といった使い方ができるでしょう。

サーバーインフラ：IaCのコード生成

サーバーインフラの分野でも使えそうです。AWSやGoogle Cloudの設定をコードで管理するTerraformなどのIaC (Infrastructure as Code) ツール。クラウド側の仕様変更は頻繁で、設定ミスは重大な障害につながります。最新のプロバイダードキュメントをClaudeに参照させながら設定コードを書かせることで、ハルシネーションによる設定ミスを減らし、堅牢なインフラ構築に役立つはずです。

まとめ

AIを使って楽をしようとした結果、逆にAIの特性について深く学ぶことになりました。CodexもClaudeも素晴らしいツールですが、あくまで「道具」です。使う側がその特性を理解していなければ、宝の持ち腐れどころか、トラブルの原因にもなりかねません。

失敗はしましたが、AIとの付き合い方が少しわかった気がします。これからも、新しい技術には積極的に触れて、素人なりに試行錯誤していきたいと思います！