コードを1行も書かずにiOSアプリを出しました——DPと指揮者とバイブコーティング

2026年8月15日の今日、「ボトルダイアリー」というiOSアプリがApp Storeで公開されています（apps.apple.com/jp/app/id6763690604）。今日あったことを日記に書くと、知らない誰かの日記が届く——匿名の日記交換サービスです。毎日正午（JST）から投稿を受け付けていて、日記を書くと誰かの日記が届き、それを読めるのは2日間だけ。フォローすると翌日以降は優先的に相互配信される、という仕組みです。Web版（bottlediary.net）と同じSupabaseプロジェクトを共有していて、iOS版はそこに乗る形で作られています。

作ったのは私です。ただ、私はプログラミング初心者で、独学、コードのほとんどはAI（Claude）が書いています。今回はこの体制がなぜ成立するのかを、自分の本業であるDP（撮影監督）の職能構造と重ねて考えてみようと思います。

DPは、なぜカメラを自分で回さなくても仕事になるのか

DPは、多くの現場でカメラを自分で回しません。実際に構図を作りレンズを操作するのはカメラオペレーターです。（私はまだ思いっきり自分でオペレートする撮影ばかりですが）照明を吊るのも、自分の手ではなく照明部の仕事です。それでもDPという職能が成立しているのは、「何を撮るかを決め、上がってきた画が違うと判断でき、直す指示が出せる」からだと思います。手を動かすこと自体は、職能の本体ではありません。

これは、AI主導の個人開発にもそのまま当てはまる構造だという気がします。コードを書く手が自分のものでなくても、「何を作るか決め、上がってきたものが違うと判断し、直す指示を出す」という部分さえ人間側に残っていれば、開発は成立する。ボトルダイアリーの開発記録には、その「判断」の場面がいくつも残っています。

手を動かしたのではなく、判断した

「表示を出し分ける」と「取得経路を塞ぐ」は別問題

2026年5月30日、受信箱に「今日分の日記を書く前でも、今日届いた誰かの日記が読めてしまう」というプライバシーバグが見つかりました。原因は、「今日書いたかどうか」の判定が受信箱のバナー表示の出し分けにしか使われておらず、日記そのものを取得するクエリのゲートになっていなかったことです。画面上の見た目は正しくても、裏の取得処理は素通しだった、ということになります。開発記録にはこうあります。

「書いてから読める」ゲートは表示だけでなく取得経路（クエリ/エンドポイント）で強制しないと意味がない。client由来の日付・written判定は信用しない。

これはコードの書き方の巧拙というより、「どこにゲートを置くべきか」という設計判断の話です。表示の出し分けと、データそのものを渡さないことは、似ているようでまったく別の防御線だと見抜けるかどうかが、ここでの仕事の中身でした。

違和感を言語化する

2026年5月28日には、受信箱に小さなバナーを追加しています。フォローしている人の日記が届いたという通知をタップして受信箱を開いても、自分が今日まだ日記を書いていなければ、実際には「昨日までと同じ受信箱」が表示されるだけです。この違和感を潰すために、「今日の日記を書くと、新しい便りが届きます」というバナーと「書きに行く」への導線を足すよう指示しました。

コードの難易度としては大きな変更ではありません。ただ、この違和感自体は、実際にアプリを使う人間の側にしか見えないものだったと思います。

Codexが的外れになった回

もちろん、判断が毎回きれいに決まったわけではありません。2026年5月27日、確認メールのリンクをタップしてもアプリに戻れないという不具合を直す際、レビュー役のAI（Codex）による差分レビューが、渡した差分そのものではなくリポジトリ全体をスキャンして、無関係な別ファイルの指摘で終わってしまったことがありました。結局この時は、渡した計画の前提——セッション情報をURLから自動検出しない設定にしていたのに、既存のリンク処理は特定の種類のリンクにしか対応していなかった、という穴——を、もう一段上の見直し作業で見つけています。AIによるレビューが的を外した瞬間を、別の見直しで拾う、という場面でした。

クロスドメイン：指揮者と、"in the loop" のパイロット

「手を動かさない専門家」という構造は、映像や個人開発の外にもあります。

投資家レイ・ダリオは著書『Principles』で、組織の責任者をオーケストラの指揮者に例えています。

"The person in charge is the shaper-conductor who doesn't 'do' (e.g., doesn't play an instrument, though he or she knows a lot about instruments) as much as visualize the outcome and sees to it that each member of the orchestra helps achieve it." （組織の責任者は、シェイパー・コンダクターだ。「実行する」人というより——楽器についてよく知ってはいても自分では演奏しない、というように——結果を思い描き、オーケストラの各メンバーがそれを実現できるよう手配する人のことだ）

指揮者は音を一つも出していないのに、演奏が合っているかずれているかを判断し、直す指示を出します。この構造は、DPの仕事や、今回のボトルダイアリー開発とかなり近い気がします。

もう一つ、航空の世界にも似た構造があります。米連邦航空局（FAA）のAdvisory Circular 120-71Bは、自動操縦（オートパイロット）が機体を飛ばしている間もパイロットが取るべき姿勢について、こう定めています。

"Stay in the loop by mentally flying the aircraft even when the AP or other pilot is flying the aircraft." （自動操縦や、もう一人のパイロットが機を飛ばしている間も、頭の中で自分が飛ばしているつもりでいることで、意識の輪の中にとどまり続けること）

同じ文書は、自動操縦のモードが予期しない動きをした場合に、パイロットが適切な是正行動を取れる必要がある、とも定めています。手は動かしていなくても、意識だけは常に操縦席に置いておく。ハンドルを握っていないからといって、判断まで手放していいわけではない、ということだと思います。

ただ、AIの限界も

ここまで「判断さえ人間側にあればいい」というふうに書いてきましたが、AI側の限界もはっきりあります。

ボトルダイアリーiOSアプリの前に作った、izco （位置共有アプリ）[[https://apps.apple.com/jp/app/izco/id6763488309]] では、リリースまでにビルド（アプリを組んでみて端末に入れる）を100回以上行いました。しかも位置情報アプリなので、私が自分で動いてきちんとその情報が記録されるか、暗号化と復号が上手くいくか、家族にも入れてもらってどう見えるかチェック…と途方もない回数のテストと、それを10倍、20倍以上の回数のやり取りをClaudeと行った訳です。

「こういうアイディアがある、作って」では到底できないのが現状です。

だからこそ残る仕事

ボトルダイアリーは、コードのほとんどを自分では書いていません。それでも、表示の出し分けと取得経路のどちらでゲートを張るべきかを見抜くこと、通知から戻ってきたときの違和感を言葉にすること、実機を触って初めて分かる不具合を拾うこと、AIのレビューが的を外した瞬間に気づくこと——これらは全部、実装そのものではなく、実装が正しいかどうかを判断する仕事でした。

DPがカメラを自分で回さなくても成立するのと同じ構造で、コードを自分で書かなくてもアプリは出せる。ただ、そこに残るのが「何でもいいから任せる」ではなく「違うと判断できること」だという点は、たぶんどの職能でも変わらないのだと思います。