Claude Codeの自作アプリ例をReiさんが14分で紹介

出典: ReiさんのClaude Code自作アプリ紹介動画

非エンジニアのReiさんが、Claude Code で作ったアプリを紹介する回。動画の入口は、前に試した時の結論と、今回の手応えを並べる話です。

動画の冒頭で、Reiさんは、自分は非エンジニアで、Claude Code をたくさん使っていると話します。

続くのは、直近に出た Opus 5.5 というモデルの優秀さに衝撃を受けた、という話でした！

この回で紹介されるのは、そのモデルで最近作ったアプリ。Claude のモデルは大きく4つあり、使っているのは上から2番目の Opus だ、と説明します。

では、Opus 5.5 の何に、それほど驚いたのでしょう？ 最初に挙がるのは、主な用途がアプリ開発だということです。

非エンジニアの自分に、そんな大層な物が作れるのか。以前は、そんな疑問があったと話します。

話は少し前の試しへ戻ります。その時は、ある程度は形になるものの、最後の10〜20%にとても時間がかかる、と結論づけていたそうです。

形にはなるけれど、仕上げの手前で時間がかかる、という受け止めでした。そこが、前の結論の中身でした。

そして今回。Opus 5.5 に気楽に話しかけて出てきた物を見て、これで良くない？ と思える出来だったと話します！

Reiさん（動画 1:44〜）

さらに1段階賢くなったんだっていうことを自分の身を持って感じることができました。

続けて、この動画の進め方が示されます。細かい使い方より、どんなことに使っているかの方に価値があると考え、作ったアプリを順に見せる方針だと話します。

Reiさん（動画 1:49〜）

細かな使い方云々よりも僕がどんなことに使っているのかの方がおそらく価値かなという風に思うので、

で、私が大事だと感じるのは、前に出した結論を消していない所です。

最後の10〜20%に時間がかかる、という以前の結論。これで良くない？ と思えた、今回の手応え。Reiさんは、この2つを並べて話しています。

並んでいるから、どこが変わったのかを、聞く側が自分で測れるんですよね。

新しい手応えだけを語らず、昔の結論の横に置く。この運び方そのものが、第1章の中身です。

配信に要る道具が1本のアプリに収まると、どんな画面になるのでしょう？ 第2章は、1本目のアプリ、朝ライブの話です。

1本目のアプリは、朝ライブ。スマホのインカメラで、ライブ配信を簡単に行えるアプリだと紹介します。

画面の真ん中に、スマホのインカメラで撮った Reiさんの顔。右側には各種の設定が並び、左上に現在の時間、左下に集中タイマーが出ています。

集中タイマーは、25分集中して5分休憩する、ポモドーロタイマーです。

自分の声とBGMの音量も、配信しながらリアルタイムに確かめられるようにした、と話します。ノイズキャンセルの機能は、つけて、と頼んで実装してもらったと説明しています。

ここで強調されるのは、配信中に使いたい道具を、1本にまとめた点です。

そのまとめた一式を、YouTube へそのまま配信できる形にして、アプリとして実装した、と話します。

Reiさん（動画 2:52〜）

僕がライブ配信中に使いたいツールをですね、一式作ってこのままYouTubeに配信ができる機能を、え、アプリとして実装してみました。

この配信アプリづくりに最近はまっていて、いくつか種類も作った、と Reiさんは話します。次の章のフォーカスルームも、その中の1本です。

いやー、ここは整理の仕方に目が行きます。道具を足し合わせるのではなく、配信に要る物を1本に収めた形なんです！

2026年10月12日の朝LIVE。共演者から、このカードを投稿するサイト、どのくらいかけて作ったのか、と聞かれました。

私の答えは、昨日寝る前に作っといてと頼んだ、でした。聞かれたのはかけた時間で、私が返せたのは、いつ頼んだか、の方だったんです。

頼む時には、過去のライブで話した内容のアイデアを参考にして、とも伝えています。ゼロから考えてもらうのではなく、話してきた中身を土台にしてもらいました。

サイトの土台は Claude Code（Opus 5.5）。設計は Opus に任せ、理想の形は先に画像生成で作ってもらいました。

ただ、その時点で、サイトはまだ完成していません。投稿と操作の確認は、これからでした。

頼むことと、できたと言えること。この2つは別です。

共演者に聞かれたその朝、手元にあったのは、頼んで出てきた途中のサイトでした。

頭の中にある画面を、口で説明するだけ。それで配信アプリは本当に形になるのでしょうか？ 第3章は、Reiさんが作ったフォーカスルームの話です。

配信アプリの続きとして出てくるのが、フォーカスルーム。画面には、右側に YouTube 配信のコメントが流れ、タイマーと時計が付く縦型の画面が映っています。

狙いは、スマホを縦に置いて、作業のお供にするような配信をしたい、というものでした。

YouTube のコメントで、集中開始、作業開始します、と書くと、配信画面の左側に、書いた人のアイコンが出ます。

見ている人が書いたひと言が、そのまま画面の上の顔ぶれになる形。この仕組みも頼んだ、と話します。

誰が集中を始めたのかが、配信画面の左側で見える作りとして紹介されています。

配信テストが成功した時は、本当に嬉しかった、とも話しています！

作り方は、頭の中で想像した物を、Opus 5.5 に口でざっくり説明することでした。

Reiさん（動画 4:19〜）

口で説明して、で、ざっくりですよ。本当にざっくり説明して30分ぐらいしてできましたって言われて、

スマホを Mac mini につないでアプリを入れると、ほぼ出来上がっていた、と続きます。以前のイメージは、アプリ1つに1日か2日。30分で出るなら無限に作れる、と Reiさんは話します。

ここでの学びは、短い一言にまとめられています。

Reiさん（動画 4:56〜）

思いついたらとりあえず言ってみることが大事なんだなっていう風にこのアプリを通じて思いました。

正直、私の目が止まるのは、時間の短さより、口でざっくり、という頼み方のほうです。

頭に浮かんだ物を、整えないまま口に出せます。この敷居の低さが、私の目に止まる所です。

敷居が下がると、頼む数が増えますよね。思いついた物を、思いついた順に、次々と頼めます。

ただ、数が増えると、別の困りごとが出てきます。何を、どのAIに、いつ頼んだのか？ 頼んだ側が追えなくなる場面です。

この困りごとは、3本目のアプリの話につながっていきます。

私なら、思いついた物を口に出す回数が増えるほど、頼んだ物の一覧を先に1か所へ置きます！

2本目のアプリは、動画の直しを、自分の手ではなくAIへの指示として残す形です。第4章は、iPad 向けに作った動画編集アプリの話。

最近 iPad を買ったものの、iPad での動画編集は難しい、と Reiさんは話します。そこで作ったのが、モバイル端末専用の動画編集アプリでした。

画面に並ぶ機能は、タイムラインの拡大と縮小、再生と停止、YouTube 動画ごとにタイムラインを切り替える表示。再生速度の変更と、テロップの編集も入っています。

このアプリの特徴は、AIと会話しながら編集できること。ブラウザ上で動き、Mac mini で動いているAIとその場で会話します。編集してほしい内容を送ると、Mac mini が動いて編集してくれる環境も作った、と説明しています。

動画の上には緑のマーカーが付き、その横にAIとのやり取りが並ぶ画面。中身は、次の引用で出てきます。

Reiさん（動画 6:29〜）

ここの緑のマーカーの位置が僕の指示で、例えば、え、タブレットを映してるんだけど右にずれちゃってるから右にズームしてセンターになるように修正してくださいっていう風に、え、お願いしてみました。で、そうするとAIが返信して、え、真上のカメラをZoom1.15倍にして中央に寄せましたという風に入ってますね。

では、なぜこのアプリを作ったのか。答えは、手で直すことより、AIに残す指示の側にあります。

Reiさん（動画 6:51〜）

僕が最近AIで、え、動画編集をする中でその修正指示というのを自分が手を加えるのではなくて、ま、AIに対してどういう指示を残したかの方がなんか今後こうAIを育てるために、ま、1社員としてエディターとして育てるために重要だなっていう風に思ったので、

ブラウザ上で動くので、スマホからでも iPad からでも、編集の指示が出せます。スマホ版の名前は、動画レビュー。拡大表示、マーカー付け、ここがダメ、という送信まで、スマホだけでできると話します。

これも、一発の指示でほとんど完成版のような物が出てきた、という話でした。あとは細かいUIのこだわりをAIとやり取りしただけで、めちゃくちゃびっくりした、と Reiさんは話しています！

私の目が止まるのは、ここです。手で直すより、AIに残した指示のほうに重心を置く考え方。

動画編集の手間を減らす話に見えて、中身は、指示の残し方の話なんですよね。

Reiさんが指示を残す先は、編集のAIです。私は、指摘を受けた日の事故の日付と、私が言った原文を、ルールの置き場へ書き込んできました。毎回読まれる場所です。

私は、作り方が決まる前に作らない、という同じ種類の指摘を、2026年3月17日から9月27日までに7回しました。

注意書きはメモリにありました。でも、毎回読まれる場所には無かったんです。それで、同じことをくり返しました。

2026年8月25日には、フィードバックは、なぜそうなのかの背景を聞いて学習してほしい、とAIに頼んでいます。

私の記事より（AIエージェントに60点のままスキルを作らせない。1回分を手で直し切ってから量産する・同じ指摘は、履歴から直すの節）

今は、指摘を受けた日の事故の日付と、私が言った原文を、読まれる場所のルールの置き場へ書き込んでいます。

残した指示は、次に誰が読むのでしょう？

置き場が、毎回目に入る所かどうか。指示が効くかどうかは、そこで変わると私は見ます。

で、道具の外に置いた指示は、次に頼む時に目に入りません。毎回開く画面の中にあれば、読み飛ばされにくくなります。

残す、読む、また頼む、の往復。これが回って、やっと指示は資産になります。

残した指示は、目に入る場所に置いて初めて、次の頼みに効いてきます！

3本目のアプリは、AIに頼んだ数が増えるほど、何を誰に頼んだのかが見えなくなる、その困りごとに向き合った物です。画面の動きと Reiさんの説明を、順に見ていきます。

3本目は、Mac アプリの Overview。最近使っている Paseo というアプリの中で使える、プラグインのような物として作った、と説明します。

画面には、進行中のAIとの会話の一覧が、タスク管理のボードとして映っています。いちばん右には、AIへ指示を出す司令塔のチャット画面。Notion のように管理できる Mac アプリがほしい、と Claude Code に頼んでUIを作ってもらった経緯です。

ボードには、未着手、実行中、レビュー待ち、完了の列が並んでいます。

動画は、まず困りごとを示します。AIにいろいろ頼むと、何を誰に頼んだかがぐちゃぐちゃになる、という話です。そこで司令塔に、昨日あった Apple の発表会をマークダウンで新しくリサーチしてほしい、と頼みます。

すると、実行中の列にタスクが1つ増えます。クリックすると、司令塔から整ったプロンプトでリサーチャー役のAIとの会話が作られ、リサーチャーがまとめていく流れが画面に映っています。

この画面の狙いは、1つ1つのお願いの中身を見ることではありません。

Reiさん（動画 10:01〜）

この1番右の人とだけ会話してタスクがうまくいってるかだけを眺めたいなという風に思ったんですね。

機能は、ボードビュー、Notion のようなリストビュー、サイドバーのデザインと機能、フィルター、右クリックでの名前の変更。話は、このアプリが出来上がるまでの早さへ続きます。

Reiさん（動画 10:44〜）

僕はもうわがままなクライアントとして、指示出ししただけでこのアプリが出来上がっちゃいました。で、これでき、できてからまだ2日なんですけど、毎日ガシガシ使ってます。

iPad 版もあります。Mac アプリと同じ機能が iPad で動き、さっきのリサーチ結果も同じ物が見られて、AIのタスク管理もできる、と Reiさんは話します。

確認する先を、いちばん右の司令塔1つにしている所に、私の目が止まります。言う先を1つに絞る発想は、私にとって大事な所です！

実は、2026年10月7日の朝LIVEで、私は、AIが書ける量に人間の確認が追いつかない、と話しました。

ブログは1日24本まで書ける設定にもできます。でも、そんなに確認したくないので、2時間に1本。確認は、簡単で分かりやすいチェックだけにしている、とも話しています。

ドット（メールや予定など秘書的な仕事が得意なAI）は、思いついたアイデアを放り込む場所が1つだけ。そこに言っておけば済むので、認知の負荷が少ない、という話でした。

スマホで通知をタップすると、自宅のPCのAIが動く。そんな流れにも触れています。

2026年9月6日のLIVEでは、スマホから統括のAI一つに話せば、AI同士で全タスクが完了する仕事がかなりできるのではないか、という趣旨で話しました。

その数日後の9月10日、私は、自分が直接マスターエージェントと単発タスクを作る形に決めました。まとめ役のAIを置く体制は、そこでやめています。

そして10月2日の夜。AIへの返事に、確認が何も来ていない、と書きました。

私の記事より（dotsタスク管理を任せるほど、AIの仕事を見る場所が要るわけを解説・AIが更新して、人が見るだけの表を作るの節）

私は10月8日と9日に、見に行く先を1つにしてほしいと頼んでいました。

司令塔1つに言う Reiさんの形と、見に行く先を1つにしてほしいと頼んだ私。向いている方向は同じです！

でね、見る場所がばらばらだと、止まっている物にいつ気づけるでしょう？ 言う先を1つに絞ると、見に行く先も1つに寄っていきます。

Reiさんの画面では、司令塔に頼んだリサーチが、実行中の列にタスクが1つ増える形で映っていました。

作る速さの話が、動画の最後にまとまって出てきます。速さがここまで来たら、次に何が起きるのでしょう？ 最後の章は、3本をまとめて振り返る話。

ここで Reiさんは、3本のアプリを作るのにかかった時間を、まとめて振り返ります。

Reiさん（動画 11:42〜）

今日紹介したこれらの3つのアプリに関してはほとんど1日かかってないです。

やったことは、こういうアイデアがあるんだけど形にしてみて、と Opus 5.5 に言っただけ、という説明です。

話は、速度と完成度のバランスが一歩頭抜けてきた、という印象へ進みます。ちょっと前からこうだった、という人もいるだろう、と断った上での受け止めです。

Reiさん（動画 12:10〜）

ちょっと次の時代来たなっていう風に、え、びっくりして、

動画は、アプリ開発にハードルを感じていた人へ向けた話に移ります。

そういう人も、こういうアプリを作ってみたいんだけど、と話しかけるだけでよい、と続けます。

出てきた物を、自分の生活に活かす。そんな使い方もいいんじゃないか、という話です。

次に作りたい物として挙がるのは、在庫管理システム。理由は、オフィスの2拠点生活で、荷物がどっちにあるか分からなくなってきたから、と話します。

オフィスの2拠点生活の中で、荷物の置き場所が分からなくなってきたこと。在庫管理システムは、その困りごとが出発点の、次に作りたい物です。

まだ作ってはいない、作ってみたいと思っている段階だそうです。

今後の動画については、2つの話が出ます。具体的な指示出しの仕方と、複数の端末でAIを使う環境設定です。

正直、作る時間の話が、最後に時代が変わったという実感へ結ばれていく。この流れが、第6章の芯です。

作る手間が小さくなると、出来上がった物を前にする回数が増えます。その中で、誰がどの順で見るのか。そこを先に決めておきたい所です。

2026年10月18日、私は、共創の酒場のフルチェックを頼みました。朝LIVEで見せた、カードを投稿するサイト。今どこまでできていて、これからどうするとより良くなるか、を聞いた上での頼みでした。

結果は全部で16件。そのうち、心配の度合いが高い物が4件でした。AIがコードで確かめた上で、先に直したい所として私に示されました。

私は、その4件を前にして、全部直すとどうなるか、と聞き返しています。

10月19日には、削除、管理、規約、依頼ボードの機能を頼みました。作った後に別系統のAIに検収してもらうと、要件の指摘が7件、不具合が10件（高が1件）。全部直しています。

頼む、出来る、見る、直す、の一回り。作る手間が減った分、この一回りの中で、誰がどの順に見るかが前に出てきます。

速く作れる時代ほど、できた物を誰がどの順で確かめるかが、仕事の真ん中に残ると私は思います！

私なら、作る速さの話を聞いたら、次に、誰が何で確かめるかを先に決めます！

動画は、Opus 5.5 で一段賢くなったという実感から始まり、朝ライブ、口で説明して約30分のフォーカスルーム、iPad の編集アプリ、Overview と進みます。最後は、3本がほとんど1日かからなかったという Reiさんの話でした。

私が持ち帰ったのは、頼む先と見に行く先を絞る見方です。指示は、残す場所と読む人まで決めておきたい所です。そして、話しかける先を絞れば、見に行く先も絞れます！

作る速さが上がった分、できた物を誰がどの順で見るかも、一緒に決めておきたいですよね？