チャットでアプリを作っていたら、いつの間にかClaude Codeを使うようになった——なぜ世間でClaude Codeが騒がれているかその理由が分かった
税理士事務所のIT環境を自力で作っている記録。今回はその最新章、「AIとの共同開発がチャットからターミナルに移った話」です。
Coworkで十分だと思っていた
Claude Codeが巷で話題になっているのは知っていました。エンジニアを中心に活用されていて、バイブコーディング（日本語で指示を出すことで生成AIにコードを生成してもらう方法）が流行っていると聞いていました。でもターミナルを利用する必要があると聞いて、やはりちょっと難しいのではないかと思っていました。
ただ、非エンジニア向けにはCoworkもあるし、これを利用すれば非エンジニアとしては十分に生成AIを活用できていると思っていました。ただ、アプリを作るのに実際に利用していたのはCoworkではなくチャットでした。
チャットUIで十分だった時代
事務所の業務改善のために、Claudeのチャット画面でアプリを作り始めたのが2026年の2月頃でした。
最初に作ったのは、Slack上で動く電子申告の送信依頼Bot。「こういう機能がほしい」とチャットで伝えると、Claudeがコードを書いてくれる。それをダウンロードして、自宅のNASにアップロードして、Dockerコンテナを再起動する。これで動きました。
v1、v2、v3とバージョンを重ねていくうちに、顧客検索機能がつき、連続入力ができるようになり、DM通知が飛ぶようになった。GAS（Google Apps Script）も同じ要領で、チャットでコードを受け取ってGASエディタに貼り付ける。InvoiceCollector、GmailFilterSync、DomainSync、NotionTaskDigest……気づけば10本近いスクリプトが稼働していました。
この段階では、チャットUIで何の不満もありませんでした。Claudeに聞いて、コードをもらって、自分で設置する。それだけで事務所の業務がどんどん楽になっていく。十分すぎるほどでした。
手動だからこそ分かったこと——セキュリティと構造の「勘所」
ただ、この「自分で設置する」プロセスが、振り返ると非常に大きな意味を持っていました。
たとえばSSH接続。初めてNASにターミナルから入ったとき、「本当に入っていいのか？」という確認メッセージが出て、yesと打つ瞬間の緊張感。あれは、ネットワーク越しにマシンを操作するということの重みを身体で理解する体験でした。
認証トークンの管理もそうです。SlackのBot Token、kintoneのAPIトークン、GASのWeb App認証トークン。これらは.envファイルに書いて、Dockerの環境変数として渡す。Slackのチャンネルに書いてはいけない。この感覚は、自分で認証の仕組みを設定したからこそ理解できました。
Dockerのマウント構造も、痛い目を見て覚えました。ある日、NAS上でファイルを差し替える際に、なぜかapp.pyという名前のフォルダを作ってしまった。当然Dockerは起動しない。原因を突き止めるまでに時間がかかりましたが、「コンテナの中からは/app/app.pyというパスでファイルを参照している」「NAS側のファイルがそのパスにマウントされている」という構造を、この失敗で理解しました。
別の日には、新しいPythonスクリプトをNASに置いたのにコンテナから見えない、という問題にぶつかりました。原因は、マウント設定がフォルダ単位ではなくファイル単位だったこと。app.pyとrequirements.txtの2ファイルだけが個別にマウントされていたので、3つ目のファイルを同じフォルダに置いても、コンテナの中には届かない。これも、自分でDocker管理画面のマウント設定を見て初めて理解できたことです。
GASのデプロイも同様です。「新しいデプロイ」と「デプロイを管理」の違い、Web Appの実行ユーザー設定、スクリプトプロパティにトークンを格納する方法。全部、自分の手でやったから分かります。
**これらは全部、のちにClaude Codeに任せることになる作業です。**でも、一度自分でやっていなかったら、Claude Codeが裏で何をしているのか分からないまま使うことになる。エラーが出たときに「マウントパスの問題だな」と判断できるのは、自分でやって失敗した経験があるからです。
バージョン管理の限界——ファイル名管理からclaspへ
バージョン管理も最初は手探りでした。初期の管理方法は素朴なものです。Claudeにコードを書いてもらうとき、「ファイル名にバージョン番号をつけてください」とお願いする。app_v1.py、app_v2.py、app_v3.py。NASにアップロードするときは旧ファイルを削除して、新ファイルをアップして、app.pyにリネームする。旧バージョンはそのまま残しておけば履歴になる。
v3くらいまではこれで回っていました。でもv5を超えたあたりから、管理が追いつかなくなってきました。
4,000行を超えるコードを、チャット画面でやり取りする。構造が少しでも違うのが怖いので、最初はコードの全文を毎回書いてもらっていました。途中から「置き換え」という方法を教えてもらい、変更前と変更後のコードを両方出力してもらうことで一部分だけ差し替えられるようになりました。しかし一部だけ差し替えると、どのバージョンでどの項目が変更されたかの履歴がコード冒頭のコメントに残らなかったり、いろいろな問題も出てきます。
ダウンロードして、NAS上のファイルを削除して、アップロードして、リネームして、Dockerを停止して、開始する。1ファイルならまだいい。でもnewsletter_bot.py、newsletter_lib.py、newsletter_processor.py、GAS側のNewsletterSender.gs……複数ファイルをまとめて差し替えるたびに、手順を間違えるリスクも高まります。
そんなときに出会ったのがclaspでした。Google公式のCLIツールで、GASのコードをターミナルから管理できます。コードをローカルに保存しておくことができます。clasp pullで最新のコードを取得、clasp pushで反映。たった数秒です。
claspを導入するときも、地味なハードルがありました。npm install -g @google/claspを実行したら、そもそもNode.jsが入っていない。winget install OpenJS.NodeJS.LTSでインストールして、PowerShellを再起動して、ようやく動く。Apps Script APIの有効化を忘れてclasp cloneが失敗する、というのもお約束のつまずきです。
でも、claspが動いた瞬間に世界が変わりました。GASエディタを開かなくても、ターミナルからコードの取得と反映ができる。ファイル名でバージョンを管理するのではなく、Gitで履歴を管理できる。
この体験が、Claude Codeへの移行を決定的にしました。「ターミナルでコードを管理する」という感覚を掴んだことで、「じゃあClaude自身がターミナルにいたら？」という発想に自然につながったのです。なんでみんながClaude Codeを利用しているかその理由がようやくわかりました。
Claude Codeで変わったこと——全体を俯瞰できる
Claude Codeに移行して、最も大きく変わったのは「受け渡しのサイクルが消えた」ことです。
チャットUI時代は、こうでした。
Claudeに今の最新コードを渡す
Claudeにコードを書いてもらう
ダウンロードする
NASの旧ファイルを削除する
新ファイルをアップロードする
ファイル名をapp.pyにリネームする
Dockerを停止→開始する
しかもステップ1が曲者でした。複数のコードが関係している場合、関連するコードをすべて渡さないと、関数名が重複したり、スクリプトプロパティの変数名が食い違ったり、いろいろな問題が出る。そのたびにやり取りしながらエラーを解消する必要がありました。
ところがClaude Codeでは、最新のコードをすでに把握している状態から始まります。上に書いた7ステップが「ターミナルで指示を出す」の1ステップになりました。ファイルの編集も、テストの実行も、デプロイも、全部ターミナルの中で完結します。
でも、それだけなら「便利になった」で終わる話です。本当に価値があるのは、プロジェクト全体を俯瞰できることです。
チャットUIでは、1回の会話で扱えるのは基本的に1ファイルです。app.pyの修正をお願いしたら、app.pyの中身だけを見てコードを書いてくれる。でも実際のシステムは、複数のファイル、複数のアプリが連携して動いている。
Claude Codeは、プロジェクトのフォルダ構造をまるごと把握できます。すると何が起きるか。
「newsletter_bot.pyとetax-botのapp.pyで、同じようなSlack認証処理を書いていますね。共通ライブラリに切り出しましょうか？」
こういう提案が来るようになる。チャットUIでは絶対にできなかったことです。1ファイルずつ受け渡していた時代には、コードの重複に気づくことすらできなかった。
GAS群も同様です。10本近いスクリプトがあると、同じような処理——kintoneへのAPI呼び出し、Slackへの通知、エラーハンドリング——が各所に散らばっています。Claude Codeなら、これらを横断的に見て、共通関数の抽出や設計の一貫性を保つ提案をしてくれる。
**たくさんのアプリを作りたい人にとって、これは必須の能力です。**個々のアプリを作るだけならチャットUIでも十分。でも、アプリが5本、10本と増えてくると、「システム全体」を誰かが見ていないと、重複だらけの保守不能なコード群が出来上がる。Claude Codeは、その「全体を見る目」になってくれます。
「裏で何をやっているか分かる」から任せられる
ここまで読んで、「じゃあ最初からClaude Codeを使えばいいじゃないか」と思う方もいるかもしれません。エンジニアであればそれもできるでしょう。しかし非エンジニアにとっては、実際にコードを配置する作業をいったん自分の手でやってみる経験が必要だったと感じています。
Claude Codeが裏でやっていることは、私が手動でやっていたことと同じです。ファイルを作って、所定のパスに配置して、Dockerを再起動する。GASにpushして、テスト関数を実行する。認証トークンを環境変数に設定する。
でも、それを理解せずに使うのと、理解した上で使うのでは、まったく意味が違います。
エラーが出たとき。Claude Codeが「マウントされていないファイルにアクセスできません」と言ったら、「ああ、Docker Composeのvolumes設定を変えないといけないな」と分かる。「認証エラーです」と言われたら、「.envのトークンを確認しよう」と判断できる。
セキュリティの判断も同じです。Claude Codeが「このトークンをコードに直接書きますか？」と提案してきたら、「いや、.envに入れて環境変数で渡してください」と自分で指示できる。何を外部に露出してよくて、何をしてはいけないか。その判断基準は、手動時代に身体で覚えたものです。実際にClaude Codeを利用していても、セキュリティ上重要なプロパティやキー・トークンは手動で配置できる必要がありますし、そのほうが安全です。
Claude Codeを使っていると、操作のたびに承認を求められます。この承認ステップは煩わしいようで実は重要で、エージェントが勝手に動かないように自分の目で確認していく必要があるものだと感じています。
改修のスピードが変わると、完成度が変わる
もうひとつ、Claude Codeで大きく実感したことがあります。自分で作ったアプリの改修や改善にかかる時間が、劇的に短くなりました。
初めに作ったものは、とりあえず動くには動く。でも実際にどのような動きをするのかを見てから、「こう動いてほしい」と思うことがかなり多い。最初から求めるものにはなりません。チャットUI時代は、この改修の1サイクルに手間がかかるため、「まあこれでいいか」と妥協しがちでした。
Claude Codeでは改修の1サイクルが圧倒的に速い。だからどんどん直せる。どんどん良くなる。結果として、アプリの完成度がまるで変わりました。
結局のところ
AIに仕事を任せるということは、「自分がやっていた仕事を、理解した上で委任する」ということなのだと思います。理解していないものは、正しく委任できない。委任した結果の良し悪しも判断できない。
チャットUIでアプリを作り、手動でファイルを差し替え、認証を設定し、バージョンを管理し、失敗し、学び、ツールを導入し——その積み重ねの先に、「Claude Codeに任せる」という選択肢が自然に現れました。
手放すために、まず自分でやる。遠回りに見えるかもしれませんが、それが一番確実な道だったと思います。
このnoteでは、税理士事務所のIT環境を自力で構築してきた記録をシリーズでお伝えしています。
シリーズ過去記事：
鎌原輝明税理士事務所では、税務申告や経理のご相談はもちろん、業務効率化のためのツール選びやIT活用のアイデアもお伝えしています。 お問い合わせは kamaharatax.com から。
