チャットAIで設計して、Claude Codeで実行する。「電卓とExcel」から学んだAI使い分けの発想。

おはようございます、がありっくです。

今回は、AIのコストを意識しながら活用を止めない、という話をします。

「電卓オジサン」になりたくない

少し大げさかもしれませんが、このままだと将来の「電卓オジサン」になりそうだという危機感があります。

Excelが登場した頃、おそらく「パソコンなんて信用ならない、電卓が一番確実だ」という感覚の人もいたと思います。でも今、Excelなしに多くの業務は成り立ちません。

同じことがAIでも起きていると感じています。チャット型生成AIと自律型AIエージェントの関係は、電卓とExcelの関係に近いんじゃないかと。

電卓とExcelの本当の違い

FP&Aとして業績管理や事業計画をExcelでやっていると、電卓を使いたくなる場面があります。

例えば予実差をちょっと確認したいとき。複雑なシミュレーションExcelのロジック検証で、KPIを動かしたときにKGIが期待通りに動いているかをざっくり掛け算で確認するとき。

Excelのセルで計算することもできます。でも電卓の方が早かったりする。そして何より、メインのExcelにテンポラリな数式が残るリスクがない。

Excel上でちょっとした計算をするとき、つい元のファイルに数式を打ち込みがちです。で、それを忘れて保存して、後日「これなんだっけ？」となる。本来やろうとしていた作業から意識が一瞬でも離れてしまう。

電卓はメインパイプラインにコンテキストの汚れを残さない。これが電卓の本当の価値だと思っています。

チャットAIも同じです。ちょっとした設計の壁打ち、論点の整理、指示書の下書き——これをClaude Codeでやると、トークンを消費しながらメインの作業コンテキストが散らかる。チャットAIでやれば、メインパイプラインを汚さずに設計できる。

なぜ使い分けを始めたのか

Claude Codeを使い込んでいくうちに、こういう懸念が出てきました。

「私の指示が曖昧なせいで、Claude Codeのトークンを無駄に消費しているんじゃないか」

特に私は言語化があまり得意ではないので、その言語化と構造化、やること・やらないことの整理を別のAIに頼めないかと考えました。

設計はチャットAI（サブスクで実質使い放題）、実装はClaude Code（従量課金でトークンを意識する必要がある）という役割分担です。

「コピペのひと手間」が逆に価値だった

この使い方には一つ手間があります。チャットAIとのやり取りの結果をClaude Codeに渡すために、コピペが必要なことです。

最初は面倒だと思っていました。でもやっていくうちに、この手間が逆に意味があると気づきました。

コピペするために必然的に中身を読む。

構造化された文章を読む中で、自分でも気づいていなかったことが整理される。人間の判断をちゃんと入れるタイミングになる。

例えば事業計画シミュレーションのダッシュボードを作るとき、最初は「Excelのシミュレーションをスクリプト化すればダッシュボードできそうじゃん」くらいの感覚でした。

でもチャットAIと相談すると、こういう段階に分けて実装しようという方針になりました。

1. ロジック用スクリプト構築・検証：車で言えばエンジンを作る段階

2. ダッシュボードの目的・利用者・UI/UX設計：車で言えば車体のデザインをする段階

3. 1のロジックを②に組み込む：車体にエンジンを載せて走れるようにする段階

確かに、と思いました。一足飛びにやってもいいものはできない。この分解をコピペしながら読んだことで、自分がやろうとしていることの全体像が見えた気がしました。

もう一つ気づいたのが、「自分が答えられることにトークンを使わない」という判断ができるようになったことです。

チャットAIが「Claude Codeでこの指示を出してこの内容を確認してください」と言ってくることがあります。例えば「この集計数値のデータソースは何か？」という確認です。

これはClaude Codeに投げれば答えは来ます。でも、私が直接答えられる内容にトークンを使うのは無駄です。チャットAIを間に挟むことで、こういう判断を自然に入れられるようになりました。

トークン消費は減ったのか

正直に言うと、事前にチャットAIで設計するようになったことで、Claude Codeにやらせるタスクが複雑になりました。トークン消費のペースとしてはあまり変わらない、もしくは少し増えたかもしれません。

でも、事前設計をしていなかったら、無駄に行ったり来たりをClaude Code上で繰り返して、アウトプットのスピードも圧倒的に落ちていたと思います。

コストを下げるためではなく、同じコストでより価値の高い作業をするための使い分けだったと今は理解しています。

まだ改善の余地がある

この使い分けにはまだ課題があります。

以前の記事でも触れたClaude Code・Codex・Gemini CLIの使い分けを、ここに組み込めるとさらに良くなるはずです。

理想は「調査はClaude Code、実装はCodexやGemini CLI」という流れです。でも今は、調査→実装→検証のコンテキストをCLIツール間でうまく引き継ぐやり方がまだ見つかっていないので、全部Claude Codeでやってしまっています。

これも今後の試行錯誤のテーマです。また報告します。

以上、がありっくでした。