Claude CodeでMacアプリを作る
(indragie.com)- Claude Codeで2万行を超えるmacOSアプリのコード全体をほぼすべて生成して公開し、自分で書いたコードは1,000行未満だった
- AIコーディングエージェントの登場によって、従来のIDEではなく、プロンプト中心の開発体験をするようになった
- SwiftとSwiftUIのコード生成にはやや限界があるものの、プライミング、コンテキストエンジニアリング、フィードバックループの設計で品質を高められる
- 自動化、デプロイ、ドキュメント化、テストまで大半をClaudeが処理し、反復的な手作業と時間消費を大幅に減らせる
- 未来のIDEはコードエディタの代わりに、エージェント活用とコンテキスト管理が中心となる新しいUXへ進化していくだろう
Claude CodeだけでmacOSアプリを公開した体験
プロジェクト概要
- 最近、ContextというmacOSネイティブアプリを公開した。MCPサーバーのデバッグのための開発者ツールである
- このアプリはほぼ100% Claude Codeで作られた。約2万行のうち、自分で書いたコードは1,000行にも満たない
- Claudeでソフトウェアを作るには、依然として開発者の実力や反復作業、プロンプト作成のスキルが必要である
- 本稿では、Claude Codeを使ってアプリを作る全工程、ツール選定、長所と短所、高品質なコード生成のための方法などを詳しく説明する
1. CopilotからClaude Codeへ、そして開発環境の変化
- 最初に使ったAIコーディングツールはGitHub Copilotで、単純な自動補完だけでも開発効率が大きく上がることを実感した
- その後、CursorのエージェントモードやWindsurfなど、コードベースからコンテキストを収集し、ビルドやテストの反復まで自動化するエージェント型ツールが次々と登場した
- Claude Codeは従来のエディタ（例: VS Code）と違って、ターミナル専用でプロンプト入力中心の純粋なエージェント環境を志向している
- 従来のIDE機能の大半を省き、プロンプトボックス1つと結果だけを見せるシンプルなUXである
- コーディングエージェントが従来のIDEを補助するのではなく、IDEそのものを置き換えようとする試みである
- ユーザーインターフェースと使用体験が既存ツールと異なるためUXには懐疑的だったが、新しいアプローチに魅力を感じて使ってみることにした
2. サイドプロジェクトを再開する
- 仕事と並行して開発する多くの開発者と同じく、未完成のサイドプロジェクトばかりが積み上がっていく
- プロトタイプはすぐ作れるが、最後の20%の完成段階で時間とエネルギーが足りず、実際の公開までたどり着けない
- MCPサーバーをテストする体験の中で、ネイティブアプリが必要だと感じ、自分でアプリを作ることにした
- この過程でClaude Codeを本格的に活用し始め、AIエージェントが実際にどれほど大きな助けになるかを実感した
3. Claude Codeの優れたコード生成能力
- 最新のSonnet 4、Opus 4モデルを使うClaude Codeは、本当に良いコードを素早く生み出す
- プロジェクトの文脈を読み、コードスタイルを把握し、関連ドキュメントや仕様を読んで機能を実装し、テストコードまで自動で書く
- ビルド、テストの反復、コンソールログやスクリーンショットの分析、バグ修正までほぼ自動化される
- 実際に開発者がコードを書く時間のごく一部だけで、高品質な成果物を生成できる
- 新入社員が何の文脈もなくプロジェクトに投入されても、数分で機能を完成させるようなレベルを実現している
4. SwiftとSwiftUIサポートの実際の品質
- Swift 6.1、macOS 15.5、最新のSwiftUIを活用した
- ClaudeはSwift 5.5までは概ねうまく扱えるが、並行性など最近の変化には弱い
- モダンAPIとレガシーAPI、Objective-CとSwiftUIを混在させてミスすることもある
- SwiftUIコードについては初稿がやや未完成で粗いものの、反復的に指示すれば十分に洗練される
- UIコードが複雑なときはコンパイラエラー（型推論失敗など）が発生するが、Claudeはこれを自動でより小さな関数にリファクタリングできる
- CLAUDE.mdファイルに指針を明示すると、Claudeのコード品質をさらに一段引き上げられる
- 例: SwiftUIを優先して使う、Apple Human Interface Guidelineに従う、最新のmacOSおよびSwift6機能を積極的に活用する、など
- さらに、agent-rules リポジトリのガイドラインを活用すると、より高品質なコード生成が可能になる
5. 「もっときれいにして」と頼める
- Claudeに「もっと美しく/エレガントに/使いやすくして」などの簡単なプロンプトを与えるだけで、UIデザインを改善できる
- UIのバグや改善点は、スクリーンショットをClaudeに貼り付けて反復的にフィードバックすれば即座に反映される
- より体系的には、まず「どうすればUIがもっと美しくなるか提案して」と頼み、その中から望む変更だけを選んで適用させることもできる
6. コンテキストエンジニアリングの重要性
- 最近のAIモデルは、不完全なプロンプトや文法的な誤りがあってもかなりうまく理解する
- 本当に重要なのは、限られたコンテキストウィンドウ（200kトークン）の中に必要な情報だけをできるだけ配置することである
- Claudeは会話の文脈が埋まると自動要約（compaction）後にコンテキストを再設定するが、この過程ではディテールの欠落や品質低下のような情報損失のリスクがある
- したがって、**限られた文脈の中でできるだけ高い品質を引き出す「context engineering」**がAIエージェント活用の中核課題になる
7. エージェントのプライミング
- このcompactionの過程で重要な文脈が抜け落ちることがあるため、必要に応じて手動で要約させたり、追加情報をプライミング（事前に読ませること）したりするのが効果的である
- CLAUDE.mdに加え、特定のソースコードや仕様書などを事前に読ませて要約させるプロンプトを書くと、出力品質が向上する
- 新しいライブラリや最新APIなど、Claudeの知識cutoff以降に登場した内容も、特定のツール（Context7、llm.codesなど）でドキュメントを変換し、Claudeが理解しやすい形にできる
- プライミングとは、「このソースファイル・ドキュメント・仕様を全部読んで要約してみて」のように指示して、Claudeが先に文脈を完全に理解するようにする過程である
8. エージェントには明確な仕様（Spec）が必要
- Claudeに機能実装を任せるときは、必ず具体的で詳細な仕様を入力しなければ望む結果は得られない
- デモでよく見せる「1文のプロンプトでアプリを作る」は、実際にはプロトタイプレベルまでしかできない
- 仕様が精密でなくても、音声入力やタイピングなど楽な方法で説明すればよい
9. 「Ultrathink and Make a Plan」
- Claudeが無計画に実装へ突入すると出力品質が下がるため、'think' や 'ultrathink' などの拡張的思考モードでまず計画を立てさせる戦略が効果的である
- 段階ごとに実装前の計画をレビューし、フィードバック後に作業させると品質が上がる
- Anthropicの**Claude Code: Best practices for agentic coding**文書は必読資料として推奨される
10. フィードバックループの構築
- Claude Codeの真の強みは、独立してフィードバックループを回せるときに最大化される
- つまり、Claudeが自分でコードを修正し（変更）、ビルドし（テスト）、失敗原因を分析して（コンテキスト収集）、再び繰り返す自動化サイクルを作ることが核心である
- このループをうまく設計するほど、Claudeはより自律的に高品質なコードを完成させられる
- 1. Build（ビルド）
- Claudeはアプリをビルド（コンパイル）する過程を自ら実行できなければならない
- Swiftパッケージなら
swift buildコマンドで簡単にビルドでき、Claudeも自然に処理できる - しかしmacOSアプリのターゲット（例: Xcodeプロジェクト）の場合、どの
xcodebuildコマンドを使うべきかClaudeがしばしば混乱する - この問題を解決するため、XcodeBuildMCPというツールを使い、Claudeがアプリのビルドと実行をより簡単に行えるよう単純化されたインターフェースを提供した
- 2. Test（テスト）
- Claudeはコードをビルドした後、自動でテストを実行し、その結果を分析できなければならない
- Swiftパッケージは
swift testで自然にテストを実行でき、Claudeもこの過程をうまく処理する - まだアプリ全体のテストやUIテストをClaudeが直接回すことは試していないが、これにもXcodeBuildMCPのようなツールが必要になるだろう
- テスト結果（成功/失敗ログ）をもとにコード修正ループを続けていく
- 3. Fix Bugs（バグ修正）
- Claudeはデバッグのためにログを追加する方法で問題を追跡できる
- ただしClaudeが直接アプリを操作してログを発生させることはできない
- ユーザーが手動でアプリを操作した後、コンソールのログをコピーしてClaudeに貼り付ける過程が必要である
- この方法も実用的には十分機能するが、ユニットテストやUIテストをあらかじめ十分に書いておかなければ完全な自動バグ修正は難しい
- Webアプリではplaywright-mcpのようなブラウザ自動化ソリューションがあるが、ネイティブアプリにはまだ確かな代替が不足している
- 4. Fix UX Issues（UX課題の修正）
- UI/UXの課題改善には、スクリーンショットをClaudeに直接貼り付けて反復フィードバックを与えられる
- Peekabooのようなツールでスクリーンショットを自動化することも可能だが、まずアプリを望む状態まで手動で操作しないとスクリーンショットを撮れない点は限界である
- つまり、UX関連の自動化にも依然としてユーザーの介入が必要である
11. Claude Codeはコードを書く以上のことをする
- Claude Codeは汎用大規模言語モデル（LLM）を基盤に動くため、コード作成以外にもさまざまな非開発業務に活用できる
- たとえば、アプリ内コピーの編集、リリース計画の策定、機能改善の方向性提案など、開発以外の作業も自然にClaudeへ依頼できる
- 特に便利だった点の1つは、実データがない初期段階でMockデータを自動生成してくれる機能である
- Contextアプリの開発当時、Swift向けMCPクライアントライブラリがまだ完成していない状況でも、UIプロトタイプ作業を進めたかった
- 本来であれば、現実味のあるモックデータを自分で作る作業は非常に面倒で時間もかかるため、実際には試さなかっただろう
- しかしClaudeは数秒で非常にもっともらしいMockデータを自動生成し、実物とほとんど見分けがつかないほどのUI状態を作ってくれた
- 実際にUIを友人たちに共有するときも、このMockデータをもとにしたスクリーンショットを使い、実サービスと同等の印象を与えられた
- MCPサーバーの場合、当時は公式仕様の一部機能しか実装されていないケースが多く、実データを得にくい状況だった
- それにもかかわらず、Claudeが生成したMockデータによって、UI全体の流れと機能動作を検証できた
12. 高品質な自動化の実装が（ほぼ）無料になった時代
- ソフトウェア公開の最後の20%で最もつらい部分の1つは、アプリのリリース工程の自動化である
- 特にmacOSアプリでは、**コード署名、ノータリゼーション、パッケージング（DMG作成）**など複雑な配布手順が多く、手作業や不安定なスクリプトのせいで公開が遅れることが多かった
- 従来はfastlaneなどの自動化ツールを無理に設定したり、最低限のPythonスクリプトを自分で書いて対応したりしていた
- 今回のプロジェクトでは、数時間の反復プロンプトとデバッグだけで、Claudeが完全なリリース自動化スクリプトを生成した
- このスクリプトが担う主な作業:
- 環境セットアップ確認: 必要なツールが正しくインストールされているか点検
- 変更ログの自動生成: gitコミットから変更履歴を抽出し、手書き項目と合わせてHTMLリリースノートを生成
- アプリのビルドとパッケージング: アプリのビルド → コード署名 → ノータリゼーション → DMGパッケージングまで全工程を自動化
- Sparkle更新フィード（appcast）の生成: 既存ユーザーに自動アップデートを配信
- リリースタグと配布: GitHubにタグを追加し、リリースを公開
- Sentryシンボルのアップロード: クラッシュレポート解析のためのデバッグシンボルを自動アップロード
- スクリプト完成後、「CLI出力をもっときれいにして」という1行のプロンプトだけでCLI UI改善まで実現した
- 最終結果は約2,000行に及ぶPythonコードで、手作業なら必須機能だけ実装して終わっていただろうが、Claudeのおかげで高品質に仕上げられた
- この自動化スクリプトのおかげで、リリースのたびに毎回数十分の反復作業を節約できるようになった
- 自然言語で仕様を説明し、実行中に見つかったエラーだけをClaudeにフィードバックして修正させれば、大半の作業は完了する
13. 未来のIDEは完全に変わる
- 今回のプロジェクトを進める中で、実際に**最初から最後まで使ったツールはClaude CodeとGitHub Desktop（diff確認用）**の2つだけだった
- 従来型IDEの中核機能であるファイルツリー、コードエディタ、拡張機能、プラグインなどはほとんど必要なかった
- まれにXcodeを開いて直接コードを修正したことはあるが、Xcode特有の機能（例: SwiftUI Previews、View Debuggerなど）もほとんど使わなかった
- 今こそAIコーディングエージェントの能力が最も低い時点なのだから、今後IDEはまったく新しい形へ進化していくはずだと感じた
- Copilot、Cursor、WindsurfなどはいずれもVS Codeを出発点に機能追加したものだが、VS Code自体は20年前のJetBrains IDEとほとんど変わらない
- Warpのようなプロジェクトはターミナルを現代化してエージェント開発環境へ変えようとしているが、ターミナル中心のUXも未来の究極的な答えではないと評価している
- 未来のIDEの核心は、開発者がエージェントのコンテキストを効果的に準備（priming）し、フィードバックループを設計・管理できるようにすることにある
- つまり、コードエディタ中心ではなく、エージェント活用とコンテキスト管理中心のUXへ大きく変化するだろうという見通しである
14. 再びサイドプロジェクトを公開できるようになった
- 今回の旅で最も印象的だったのは、素晴らしいアプリを作れたこと以上に、再び自分のサイドプロジェクトを実際に公開できるようになったことだった
- まるで毎日5時間の追加時間を得たような感覚で、その対価は月額わずか200ドルにすぎない
- Claude CodeのようなAIコーディングエージェントのおかげで、長いあいだ先送りしてきたアイデアを現実へ移す原動力と自信を再び得られた
2件のコメント
もっとやれ
Hacker Newsのコメント
2年前までは自分は本当に優秀なPythonエンジニアだと自負していたのに、今ではネイティブモバイルアプリ、Slackと連携するデスクトップアプリ、Goで書いたAPI、ReactベースのフルWebアプリまで、数日あるいは数時間で作れるようになった。
まるでスーパーパワーを手に入れた気分で、生産性・速度・創造性が湧き上がってくる感じだが、その一方で奇妙な悲しさも感じる。
自分の仕事、自分の情熱、自分が長い時間をかけて身につけ、犠牲まで払ってきたことの大半が、今や機械によって置き換えられつつある。
こうしたツールを作る企業は、まだ出発点に立ったばかりだ。
次の世代のエンジニアにとってこれが何を意味するのか、この流れがどこまで続くのか気になる。
同じような感情を抱いている人がいるのか知りたい。
複数のプラットフォームでネイティブ、モバイル、Go、Reactなどさまざまなツールを効率よく扱えるようになったのは、Pythonエンジニアとしてのソフトウェア開発経験があるからだ。
LLMが置き換えているのは、各プラットフォーム固有の細かな知識を暗記する必要性だ。
自分はGoのforループ構文を覚えていなくても、すぐに役立つGoコードを書ける。
それでも、ループ、Goの概念、構造化プログラミング、コンパイラ、ビルドやテストスクリプトなど、基本原理を理解しておく必要があることは変わらない。
プログラミングの背景知識がない人には、この部分が大きく欠けている。
LLMは、自分の長年のキャリアで蓄積したあいまいな知識を、さまざまな言語やプラットフォームにすぐ適用可能にしてくれる増幅器であり加速器だと感じている。
以前はPython、JavaScript、SQLだけであらゆる問題を解決していたが、それは新しい言語やプラットフォームの細かな違いをまた覚え直すのが負担だったからだ。
今ではGo、Bash、AppleScript、jq、ffmpegなども進んで使うし、Swiftプロジェクトも検討している。
非専攻の人たちがLLMを使って何かを作るのを見たことがあるが、たいていはずっと遅いか、ほぼ失敗に終わる。
技術スキルは最終的に必須ではないかもしれないが、明確に意思疎通する能力は必ず必要だ。
HTMLを理解している程度でも、テキストをきれいに差し込んでLLMがより明確に理解できるようにできる。
やはり技術的な背景は強みだと思う。
産業革命以前の手工業労働者たちも似たような感情を抱いたのだろうと思う。
ただし彼らの大半は十分な教育も受けられず、子どものうち1〜2人は些細な病気で10歳になる前に亡くなり、電気・水道・屋内配管・冷蔵庫もない生活をしていたことは考慮すべきだ。
自分の手で道具を作るのはロマンがあるが（ちょうどPythonコードを手作業で書くように）、時代が進むほど、より抽象的な層で生きることのほうが、むしろ先祖たちにとっても利益だったと思う。
誰も自分で直接Pythonコードを書くことを止めないし、黒鉛細工のように趣味として楽しむ人はきっと出てくると思う。
自分が築いてきた仕事・情熱・技術を今や機械が代替している、という考えには同意しづらい。
機械は経験も予見も内省も、計画能力や創造性もなく、ただ指示に従う存在だ。
人間だけがアイデア・創造性・目標・共感能力を持ち、良いアイデアで他人を説得したり、状況に応じて文脈を考慮したりできる。
プログラミングという職業が消えるというより、はるかに高い抽象化段階へ移行しているのだと思う。
かつてはビットやバイト、アセンブリを1行も知らなくても開発者になれたし、アセンブリが必須だった時代もあった。
今ではプログラミング言語そのものを知らなくても、英語と要件さえよく分かっていればプログラムが作られる時代だ。
それでもメモリ構造、アセンブリ、低レベルの概念を知る人は、裏で何が起きているのかを依然としてより深く理解し、必要ならもっと「うまく」できる。
だからといって、上位の抽象化レイヤーが無価値になったり消えたりするとは思わない。
自分もまったく同じように感じている。
20年以上プロとしてソフトウェアを開発してきて、本当にこの仕事が好きだった。
今はClaude Codeを100%活用していて、生産性が確実に上がったのは分かるが、以前のプロセスは芸術のように感じられたのに対し、今は工業化された大量生産のように感じる。
この新しい現実の中で、ソフトウェアに深く没頭できた自分だけの何かをもう一度見つけたいし、その楽しさがかなり減ったのは確かだ。
とてもよく書かれた文章で、読むだけでも楽しい。
未来のIDEは今とはまったく違うものになるだろう。
自分もCursorから始めて、VS Code強化型IDEを使い、最終的にはClaude Codeに移行した。
その結果ターミナルの重要性が増して、iTermからGhostty（高速で軽量でモダン）、Tmux、Tmuxinator、NeoVimへとワークフローが移っていった。
catやbatコマンドでファイルを確認し、ときどきテキスト編集をするだけで、重い作業の大半はClaude Codeが担当する。NeoVimやEmacsでは仕様やプロンプトだけを書く感じで、このワークフローがとても気に入っている。
コード生成だけでなく、zsh、neovim、ghosttyなどのconfigファイルを修正するときも、Claude Codeにタスクを割り当てて変更している。
設定ファイルのリファクタリングも数分で終わる。
コードベースへの質問、コードのリファクタリング、コードのドキュメント化、コミットメッセージの生成などもすべて任せていて、本当に最高だ。
最後にコードベースへの質問、リファクタリング、コードのドキュメント化、意味のあるコミットまでやるという話が出ていたが、自分もCCで素晴らしいコミットメッセージを作らせるために、Conventional Commitsの情報と例を CLAUDE.mdファイル に入れておいたことがある。
CCは
.zshrcのような個人設定ファイルを変更する前に、自動でバックアップを取ってくれるのか気になる。Terminal + Claude Code + プロジェクトフォルダ
本当にこれだけで十分だと、ようやく分かった。
フルIDEのセットアップは面倒で元々好きではなかったし、OSごとにクロスコンパイルするにはQTの設定も複雑だったが、常にエディタとターミナルの組み合わせがいちばん理にかなっていると思っていた。
そこにClaude Codeが、もう一つ開いたターミナルウィンドウとしてリクエスト処理を手伝ってくれるので、開発者からプロジェクトリーダーへ「レベルアップ」した気分だ。
人員管理のストレスもない。
今では、昔からやってみたかったあらゆるサイドプロジェクトを、3月にClaudeが出てきてから数か月で完成させている。
1、2年前に思いついたことがある。LLMは熟練開発者にとっては優秀なアシスタントであり、熟練開発者の代わりをさせようとするとひどいことになり、未熟練の開発者にとっては危険なアシスタントだ、という考えだ。
実際に使ってみると、だいたいこの考えは当てはまる。
今では、未熟練の開発者にとってLLMが良いメンターになる可能性もあるとは思うが、現実には主に、コードがなぜ動くのか理解しないまま手当たり次第に修正し、どうにか動くまで試行を繰り返すケースのほうが多く見える。
結局そういう状況では、LLMは危険なアシスタントだという当初の考えがいっそう強まった。
こういうときは微妙なバグや問題が気づかれないままコードに潜伏し、気づいてもその原因を理解できないことがしょっちゅうある。
LLMアシスタントのおかげで、サイドプロジェクトの最後の20%を仕上げる負担が大幅に減った、という結論が特に印象的だ。
自分にとってこの旅でいちばん興味深いのは、新しいアプリそのものよりも、コーディングへの渇望が満たされ、きれいなサイドプロジェクトを再び完成度高くリリースできるようになった今の状態だ。
まるで1日に5時間増えたような感覚で、月200ドルなら十分に見合う。
自分は小さなユーティリティを作るときに主に活用しているが、本当に驚くほどうまく動く。
launchctl/launchdタスクの状態（実行中/アンロード/失敗など）をOrbStackのメニューアイコンのように表示するユーティリティを、Claudeで数時間のうちに望んだ形に実装できた。これからもっと多くの人がこうする気がするが、みんなGitHubにコードを共有すべきではないかと思う。
2008年からMac向けソフトウェアを作ってきた人なら、Claudeがどこで間違えたのかを素早く見抜いて修正できただろうと思う。
Claude Codeのようなツールは、既存のスキルと経験を増幅する役割を果たす。
決して専門性を置き換えるものではない。
結局、記事の最後でこの作業に月200ドルかかることが明らかになるが、自分はメインの趣味に不可欠なAutodeskにさえ50ドル払うのが惜しいと感じる。
こうしたAI企業は利益も出ておらず、投資家が収益を求め始めたら、コスト急騰かサービス品質低下は避けられないと思う。
これらのモデルが無断学習したコードの提供で訴訟に負ければ、ClaudeのSwift生成能力も即座に低下するだろう。
果たしてDisneyがAI訴訟で負けると期待してよいのか疑問だ。
正直、自分のコメントに意味があるかは分からないが、AI疲れは本当に深刻だ。
今の時点では、HNやその他のテックフォーラムでも、こうした投稿は禁止したほうがいいと思う。
GoogleやStackOverflowで簡単にコードが書けたという話を誰かが投稿したら、みんなつまらないと皮肉るのは目に見えているのに、こういう投稿も結局同じだと思う。
AIで趣味や仕事に「ただ乗り」する話にはうんざりしている。
WindsurfのようなツールとCLIツールを使って、自分専用のカスタムツールを作るのが以前よりずっと簡単になった。
本当に面白い時代だ。
そのうち誰かがLLMを使ってMacOSそのものを複製する時代が来るような気がする。
数週間前、LLMツールを使ってretro68とc++でsystem 6（クラシックMac）アプリ上で6DOFワイヤーフレームレンダラーを起動することに成功した。