ポイント3行
- 「まずターミナルを開きましょう」という紹介動画の推奨理由をよく見ると、自動化の話が中心でソフトウェア開発のコア作業とはズレていることがある
- 仕様の策定とレビューが開発の中心なら、テキストが読みやすく選択コメントもできるデスクトップアプリのほうが向いている
- 大事なのは「どのUIで指示を出すか」ではなく「何を作るかを正しく定義すること」
何度聞いたか分からない「まずはターミナルを開きましょう」
「まずはターミナルを開きましょう」「ターミナルに抵抗がある方もいるかもしれませんが…」
YouTubeのClaude Code紹介動画で、もう何度この前置きを聞いただろうか。
私はプログラマーだ。C#でアプリを開発している。ターミナルが怖いわけでも、使えないわけでもない。Gitの操作もビルドもコマンドラインでやれる。
それでも私はClaude Codeの作業をターミナルではなく、Claudeのデスクトップアプリで回している。別にターミナルが嫌いなわけじゃない。自分の開発スタイルにはデスクトップアプリのほうが合っていると感じているからだ。
先に結論を言っておくと、この記事は「ターミナルを使うな」という主張ではない。 ターミナルが好きなら使えばいいし、合わないなら無理に使わなくていい。ただ、多くの紹介動画が「ターミナルを使うべき」と言っている理由をよく見てみると、プログラマーの仕事の本質とはちょっとズレた話が混ざっていることがある。だから「自分にはデスクトップアプリのほうが合っている」という選択肢もあるよ、ということを伝えたい。
「ターミナル推奨」の理由をよく見てみると
Claude Codeの紹介動画でターミナルが推奨される理由として、だいたい以下のような説明がされている。
- デスクトップアプリはクラウド環境だから、自動化に制限がある
- ターミナルならローカルPCを完全に操作できる
- 外部APIとの連携やSNSの自動投稿など、完全自動化にはターミナルが必要
一見もっともらしいけど、よく考えると引っかかるところがある。
まず「デスクトップアプリはクラウド環境だから制限がある」という説明。たしかにClaudeとの対話、つまり推論処理がクラウドのAPIを介して行われるのは事実だ。でもこれはターミナル版のClaude Codeでもまったく同じ仕組みだ。デスクトップアプリでもMCPサーバーを通じてローカルファイルへのアクセスやコマンドの実行ができるし、MCPの接続設定もアプリ内から行える。「クラウドだから制限がある」というのは、ちょっと大雑把すぎる説明だと思う。
次に「ローカルPCを完全に操作できる」という話。これ自体は事実なんだけど、デスクトップアプリでもMCPやデスクトップ拡張機能を通じてローカルの操作ができるという点が抜け落ちている。たとえばファイルシステムサーバーを使えば、指定したフォルダのファイルを読み書きしたり、ディレクトリの構成を変えたりすることがデスクトップアプリ上からできる。
そして「外部API連携や完全自動化」の話。Xへの自動投稿とかショート動画の編集パイプラインとか、たしかにターミナルが活きるユースケースではある。ただ、これらはタスクの自動化であって、ソフトウェア開発のコアの作業とは少し違う話だ。
たとえるなら、料理人に「包丁よりフードプロセッサーを使いましょう」と勧めるようなもの。フードプロセッサーが便利な場面はあるけど、味見をしたり盛り付けを考えたりする作業には包丁すら必要ない。自動化の道具と、ものを考える道具は、そもそも役割が違う。
ここを混同してしまうと、「プログラマーがClaude Codeを使うにはターミナルが必須」という誤解につながりかねない。
私がデスクトップアプリを選ぶ理由：仕事の中心が「仕様のレビュー」だから
ではなぜ私はデスクトップアプリを選んでいるのか。それは、私の開発スタイルにおいて人間が最も時間を使うべき作業が仕様の策定とレビューであり、その作業にデスクトップアプリが最も適しているからだ。
仕様駆動開発という考え方
私のワークフローはざっくり4つのフェーズに分かれている。
| フェーズ | やること | 主導するのは |
|---|---|---|
| 1. 計画 | 要件を自然言語で書く → 仕様書のドラフトを作る → レビューして修正・承認 | 人間 |
| 2. インターフェース定義 | 仕様書から型定義やデータ構造を作る → 公開APIの骨組みとして妥当か確認 | AIが生成、人間が確認 |
| 3. テスト＋実装 | インターフェースに対してテストを作り、テストを通す実装コードも生成 → テストが通らなければ自動修正 | AI |
| 4. 最終確認 | 全テストがパスしていることを確認 → マージ・デプロイ | 自動化 |
このワークフローにおいて、人間の最大の仕事はフェーズ1の仕様策定だ。AIが生成した仕様ドラフトに対して「この要件が抜けている」「このエッジケースはどうする？」「この命名だと分かりにくい」といった指摘を入れていく。この作業の質が、最終的な成果物の品質を決定的に左右する。
フェーズ2のインターフェース定義のレビューも大事だ。メソッド名、引数の型、戻り値の設計が仕様と合っているかを確認する。ここさえ正しければ、フェーズ3の実装コードの正しさはテストが保証してくれる。
イメージとしては、建物を建てるときの「設計図のレビュー」に近い。設計図が正しければ、あとは施工チームが図面どおりに建ててくれる。逆に設計図に穴があると、どんなに腕のいい大工さんでもまともな建物にはならない。私の開発スタイルでは、人間が集中すべき作業はテキストの読解と添削であって、ターミナルのログを追う作業ではないのだ。
コードの差分はコミットのときに見ればいい
「ターミナルで差分をリアルタイムに確認しましょう」という話もよく聞くけど、仕様駆動開発ではAIが生成したコードの全行を逐一追いかける必要がない。テストが仕様を正しく反映していれば、テストの合否がそのまま品質の客観的な判定になるからだ。
差分を確認する適切なタイミングは、コミットするときかプルリクエストのときで十分だ。GitのGUIツールでもGitHubのプルリクエスト画面でも、変更内容は見やすい形式で確認できる。
テストで言えば「答え合わせは全問解き終わってからまとめてやればいい」ということ。1問解くたびに丸つけをしていたら、かえって集中が途切れてしまう。
デスクトップアプリが仕様レビューに向いている3つの理由
理由1：テキストが読みやすい
仕様書もインターフェース定義も、本質的には「テキスト」だ。Claudeのデスクトップアプリは長文のテキストを読みやすいフォントとレイアウトで表示してくれる。ターミナルの等幅フォントで流れるログとは、単純に可読性が違う。
仕様ドキュメントを何度も読み返して、細かい表現の曖昧さに気づく。この作業において、読みやすさは地味だけど確実に効いてくる。参考書を読むとき、きれいに印刷された本と、コマンドプロンプトに表示されたテキストのどちらが読みやすいかを想像してもらえれば分かると思う。
理由2：選択してコメントを入れられる
Claudeのデスクトップアプリには、AIの出力テキストを選択して直接コメントを入れる機能がある。これが仕様レビューに驚くほどフィットする。
たとえばAIが生成した仕様ドラフトの一節に対して、「ここ、認証エラー時の挙動が書かれていない」「この命名だと別の機能と紛らわしい」といったピンポイントの指摘を、該当箇所を選択してそのままぶつけることができる。
ターミナルでこれをやろうとすると、「上の出力の○行目の△△について…」と場所の説明から始めなければならない。仕様レビューの本質は正確な箇所に正確な指摘を入れることだ。「えーと、さっきの出力の上のほうにあったやつなんだけど…」と毎回説明しているようでは、テンポが悪くなって本来の思考に集中できない。この操作性の差は、日々積み重なると無視できない。
理由3：仕様の全体像を俯瞰できる
ターミナルでは出力が上から下へ流れていくため、過去の出力を見返すにはスクロールが必要だ。デスクトップアプリでは会話がスレッド形式で整理されていて、アーティファクトとして仕様書やコードが独立したパネルに表示される。仕様書を見ながら別のターンで質問するという作業が自然にできる。
これは紙の資料を机の上に広げて作業するのに似ている。ターミナルだと、資料を1枚ずつめくりながら作業するような窮屈さがある。仕様のような「何度も参照するドキュメント」を扱うなら、全体像をパッと見渡せる環境のほうが効率的だ。
もちろん、ターミナルが向いている場面もある
念のため繰り返すけど、ターミナルを否定しているわけではない。ターミナルが向いている場面はちゃんとある。
たとえば自動化パイプラインへの組み込みでは、コマンドラインが必須だ。複数のAIエージェントをtmuxで並行稼働させるような使い方も、ターミナルならではの強みだろう。SNS投稿の自動化や外部APIとの連携も、ターミナルが自然な選択肢だ。
大事なのは「ターミナルかデスクトップアプリか」の二者択一ではなく、自分の作業の中心が何かを見極めて、それに適した道具を選ぶことだ。
私の場合は、仕事の中心が「仕様を書き、レビューし、テストで品質を担保する」ことにあるから、テキストの読み書きに特化したデスクトップアプリを選んでいる。ターミナルでガシガシ自動化を回すのが中心の人なら、ターミナルが合っているだろう。
道具に合わせて仕事のやり方を変えるのではなく、仕事のやり方に合った道具を選ぶ。これが私のスタンスだ。
「まず仕様書を開こう。UIは好きなのを使えばいい。」
Claude Codeの紹介動画でよく聞く「まずはターミナルを開きましょう」というアドバイスは、特にプログラミング初心者にとっては有用な導入かもしれない。ターミナル操作を覚えること自体に価値はある。
ただ、プログラマーとして私が伝えたいのは、ターミナルに慣れること自体がAIコーディングの生産性を決めるわけじゃないということだ。生産性を決めるのは、要件を明確に言語化する力、インターフェース設計を評価する力、テストケースの網羅性を判断する力だ。これらはすべてテキストを読んで考える作業であって、ターミナルで行う必然性はない。
ターミナルが好きなら使えばいい。合わないなら無理に使わなくていい。AIコーディングの本質は「どのUIから指示を出すか」ではなく、「何を作るかを正しく定義すること」だから。
「まずはターミナルを開きましょう」——悪くないアドバイスだ。でも私なら、こう言い換える。
「まず仕様書を開こう。UIは好きなのを使えばいい。」
まとめ4行
- ターミナル推奨の理由をよく見ると、自動化やAPI連携の話が中心で、ソフトウェア開発のコア作業とは別の話が混ざっている
- 仕様駆動開発ではテキストの読解と添削が人間の主な仕事だから、読みやすさと操作性に優れたデスクトップアプリが向いている
- ターミナルにはターミナルの強みがあり、自分の作業内容に合った道具を選ぶのが正解
- AIコーディングの生産性は「どのUIを使うか」ではなく「何を作るかを正しく定義する力」で決まる
