Claude CodeでMacアプリを2つ作成して知ったこと
作者
팀
成功かどうか
成功
トピック
- 自動化
Claude CodeでMacアプリを2つ作成して知ったこと
コーディングができなくてもアプリを作れる時代が来たとすれば、まだ少し誇張のように聞こえるかもしれません。
私もしばらく前までも同様に考えました。アイデアはあっても開発は開発者の領域だと思いました。ところで、最近、Claude CodeとCodexを活用しながら、思考が少し変わりました。
今週は実際に2つのMacアプリを作成しました。 1つは私が一日中どのアプリに時間を費やしているかを追跡するアプリで、もう1つは家でいつも不便だったオーディオ出力を解決するためのアプリでした。
もちろん完璧ではありませんでした。 UIも足りず、中途半端なエラーも多かったです。しかし重要なのは結果ではありませんでした。
「必要なものがあれば自分で作ってみる」
この考えが初めて現実的な選択肢になったという点がもっと興味深かったです。
そしてその過程でCodexにFable構造を適用してみる実験も一緒に進めました。モデル自体よりも仕事を処理する方法と構造がより重要であることもまた確認できました。
今回の記事では、Claude CodeでMacアプリ2つを作った経験と、Codex実験を通じて得たインサイトを共有してみたいと思います。そしてこれをきっかけに始めた小さな目標一つも紹介しようとしています。
「私が必要とするMacアプリを20個自分で作成します。」
AI Nativeの時代には、おそらくこれが新しい生産性の始まりかもしれません。
思ったより簡単にMacアプリを作ることができた
最近のAIコーディングツールの話は本当にたくさん出てきます。 Claude Code、Codex、Cursorなどの新しいツールが引き続き登場しています。ところがいざ書いていないと体感しにくい部分があります。
本当にアプリ一つを作れるほど良くなったのだろうか？
今週直接実験してみました。
結果から言えば、思ったよりずっと可能性がありました。
もちろん、私が突然開発者になったわけではありません。 Swiftを深く理解しているわけではなく、macOSアプリ開発の経験が多いわけでもありません。代わりに、必要な機能を説明し、Claude Codeによって書かれたコードを確認し、問題が発生した場合に再修正するプロセスを繰り返しました。
その過程で感じたのは、AI時代の開発は以前とは少し違うという点でした。
以前は、アイデアが生まれたら、まず開発リソースを考えました。作れますか？どのくらいかかりますか？誰が開発しますか？同じ悩みが先に出ました。
さて、今は少し違います。
一度作成して判断できます。
実際、今週は単なるトイプロジェクトレベルではなく、私が実際に使っている2つのMacアプリを作成しました。 1つは作業時間を追跡するアプリ、もう1つはオーディオ出力をアプリごとに分離するアプリです。
完成度は商用サービスと比較できませんが、少なくとも私が経験している問題を解決するのに十分でした。
そしてこの経験一つだけでもかなり大きな変化だと感じました。必要な機能ができた時、これ以上「誰が作ってくれたらいい」ではなく、「一度作ってみようか？」を先に思い浮かべることになりましたから。
最初のアプリ、作業時間トラッカー
AIでアプリを作成できることを確認した後、最初に作ったのは作業時間トラッカーでした。
実際、理由は単純でした。
最近では、Claude、ChatGPT、Codexを行き来しながら働く時間が増えていますが、いつもどんな仕事にどれくらいの時間を費やしているのかはよくわかりませんでした。一生懸命働いたようですが、いざ振り返ってみるとメッセンジャーやブラウザに時間をたくさん使った日もありました。
だから自分で作ってみることにしました。
このアプリは現在使用中のアプリを追跡し、作業時間を自動的に記録します。単に総作業時間だけを表示するのではなく、どのアプリでどのくらいの時間を費やしたかを確認できます。
特に気に入ったのは目標時間を設定する機能でした。
たとえば、Claudeを活用した作業を1日1時間以上進めると目標を設定すると、進捗状況がリアルタイムで表示されます。ゲームのクエストのように目標を達成する楽しみもあり、思ったよりやる気が良くなったんですよ。
また週間・月間単位でデータを集めてみると興味深いパターンも発見できます。
「私はAIツールをたくさん使うと思いましたが、実際にはカカオトークをもっと長く見ていましたか？」
同じ事実を数字で確認することになります。
まだ機能的に欠けている部分はたくさんあります。しかし、すでに私が毎日使っているアプリになっています。そしてこの経験を通してもう一度感じました。
良いアプリが必ずしも巨大なアイデアから始まるわけではありません。
むしろ、毎日繰り返される小さな不快感の1つがより良い出発点になる可能性があります。
2番目のアプリ、Soundwich
2番目に作成されたアプリはもう少し個人的な問題から始まりました。
家で働くとき、しばしばこのような状況がありました。
音楽はBluetoothスピーカーで聴きたいのですが、仕事のお知らせや会議の音はエアポットで聴きたかったです。しかし、macOSは基本的にすべてのサウンドを1つの出力デバイスに送信するので、好きな方法で使いやすくありませんでした。
もちろん、同様の機能を提供するアプリもあります。
しかし、インストールしてみると、機能が多すぎたり、有料であったり、私が望む方法と少しずつ違いました。
それで今回は探す代わりに作ってみることにしました。
Claude Codeで機能を設計し、Xcodeで修正とテストを繰り返しました。予想より試行錯誤は多かったです。特にオーディオデバイスを制御する過程で思ったより多様な例外状況が発生しました。
それでも結果的には1日で好きな機能を実装できました。
今ではBluetoothスピーカーから音楽が出てきて、業務関連の音はMacBookスピーカーやAirPodに分離して使えるようになりました。非常に途方もないアプリではありませんが、私が毎日経験した不快感を解決するのに十分でした。
今回のアプリを作りながら一番印象深かったのは、開発難易度ではなくアプローチの変化でした。
以前同じだったら検索からやったはずです。
「この機能を提供するアプリはありませんか？」
「無料アプリない？」
「誰が作ったことはないの？」
ところで、今は考えが少し変わりました。
必要なものがない場合は、自分で作成できます。
もちろん、商用サービスレベルの完成度を作ることは依然として困難です。しかし、個人の不快感を解決するレベルであれば、AIと思ったよりも速く結果を作成することができます。
Soundwichは完璧なアプリではありません。
しかし、私にとっては、AIネイティブの時代がどんな時代であるかを最もよく見せる事例の1つでした。消費者にとどまらず、必要なものを自分で作る人になれる時代です。
Codexにペイブルを入れてみた
アプリを作成しながら、自然に1つの不思議が生じた。
「結局重要なのはモデルなのか、それとも働く方式なのか？」
最近、OpenAIのCodexを使ってこの質問をかなり多くしました。そして今回は少し特別な実験もしてみました。
すぐにFableCodexを適用してみました。
最初は、単にプロンプトの数行が追加された程度だと思いました。ところで実際に使ってみると少し違って感じられました。
Fable構造はおおよそこのような流れで動作します。
•
根拠の確認
•
計画の確立
•
仮説の設定
•
完全なコードテスト
•
検証結果の確認
•
最終適用
考えてみると、人が仕事を上手にする時の過程と大きく変わりません。
問題を把握し、計画を立て、検証し、適用する順序を強制する構造なのです。
興味深かったのは同じCodexなのに結果物がかなり変わったという点です。
従来はすぐにコードを修正したり、実装から始めることが多かったです。一方、Fable構造を適用するので、まず問題を整理し、どのように解決するかを説明した後、テストと検証まで行う割合が高くなりました。
もちろん欠点もありました。
トークンは本当によく使われます。
思ったより長い推論過程を経るため、コスト面では負担がありました。しかし、コード検証やレビューのように、間違いを減らすことが重要な作業では十分に価値があると感じました。
特に自分で作成したアプリを検証するのに効果がありました。
新機能を追加した後、「本当に問題はないか？」を確認する過程で、単純なコード生成よりもはるかに安定した結果を示しました。
今回の実験をしながら得た最大の学びは一つでした。
良い結果を作るのはモデルではなく構造であることができるということ。
モデルのパフォーマンスの違いも重要ですが、どのようなプロセスで考えて検証するのかが、結果の品質に大きな影響を与える場合もあることがわかりました。
今、必要なツールを自分で作る時代
今週作成した2つのアプリは実際には素晴らしいサービスではありません。
App Storeにリリースする予定もなく、収益を上げるつもりはありません。ただ私が実際に不便だった問題を解決するために作っただけです。
ところが、作業を終えてから最も大きく残った考えは、アプリ自体とは違うところにありました。
以前は、不快感が生じた場合はまず検索しました。
「この機能を提供するサービスはありますか？」
「無料で使えるアプリはないだろうか？」
そして、ほとんどは適切な選択肢を見つけるか、ちょうど参考に使用した。
しかし、今は選択肢がもう一つありました。
自分で作ってみること。
だから個人的に小さな実験を始めようとしています。
「私が必要とするMacアプリを20個作成する」
途方もない目標ではありません。
一日に何度も繰り返す不便さ、毎回惜しみを感じる機能、あればいいと思っていた小さな道具を一つずつ自分で作ってみようと思います。
おそらく失敗するアプリも多いでしょう。実際に使用しなくなるアプリもあるでしょう。
それでも大丈夫です。
今回の実験を通じて得た最大の学びは、結果物ではなく可能性だったからです。
AIネイティブ時代は、単に仕事を早くする時代ではありません。
思ったことを自分で作ることができる時代に近いです。
そして今回作成した2つのアプリはその最初の実験でした。
仕上げながら
多くの人がAIモデルのパフォーマンスの違いに焦点を当てています。 GPTが良い、Claudeが良い、Codexが良いような話です。
もちろんそれも重要です。
しかし、実際に複数のツールを使ってみると、もっと重要なのはモデル自体よりもどのように働かせるのかに近かったのです。
Fable構造を適用したCodexの実験もそうだったし、Claude Codeでアプリを作る過程も同様でした。
良い構造と良い問題定義があれば、思ったよりもはるかに多くのものを作ることができます。
だから今後も私は新しいサービスを探す前に先に作ってみたいと思います。
そしてその過程で私が必要とするMacアプリ20個を埋めていくつもりです。
何個も実際に最後まで使うようになるかはわかりません。ただ一つのことは確かです。
AIのおかげで、初めてその目標が現実的に見え始めたということです。