WATCH REPORT|Claude Code運用

AIに任せる範囲はどこまで?6万人が使うSNSアプリを作る開発者が、Claude Codeで決めている線引き

2026年10月2日|Shin Coding Tutorial(2026年10月1日公開)

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん(@passion_tanaka)です。今回は、Shin Coding Tutorialの「6万人が使うSNS開発でわかった、Claude Codeの本当の使い方」を紹介するね。

Shinさんの画面には、真ん中にオーナー1人、まわりに8つのセッションが並ぶ図があります。そのオーナーが、1日100〜200回の判断を返しています。6万人が使うSNSアプリを、Claude Codeで開発と運用まで回している人です。

意思決定はAIに外注しない、がShinさんの線です。私も、AIに全部は渡しません。ただ、一件ずつ見る範囲が違いました。

話している人

話しているのは、Shinさん。YouTubeチャンネル「Shin Coding Tutorial」の運営者で、Xのアカウント名は@Shin_Engineer。実名は、動画と概要欄では確認できませんでした。動画の長さは20分19秒、公開は2026年10月1日。

3行でわかるポイント
  1. Shinさんは、8つのセッションを部署に見立て、1日100〜200回の判断を1人で回している、と話しています。
  2. 私もAIに全部は渡しません。違うのは、一件ずつ確認する範囲です。私は、確認を4つの場面に絞っています。
  3. 同じ指摘を2回言ったら、メモから確認待ちや禁止の設定へ上げる。今週の差し戻し1件から始められます。

出典:Shin Coding Tutorialの動画

01

「この秘書はちょっと今現在開発ではやっていません」|束ね役を外した点は、私と近い

図解: 束ね役の席を空けて、判断の持ち主を決める。空席の椅子と、各担当へ直接つながる線
動画キャプチャ: Claude Codeのセッション一覧が並ぶ画面(2:26頃)
動画キャプチャ: Claude Codeのセッション一覧が並ぶ画面(2:26頃)

Shinさんは、以前の動画で、オーナー、マネージャー、秘書、各セッションの形を説明していました。今回は、その秘書を外した、と話しています(1:56)。

「これくらいの規模のアプリケーションになってくると、ま、明確なゴールがあったりとか、次どういう方向性に進めばいいのかみたいな話っていうのは、あの、AIだけだと絶対に決められないんですよね。」

Shinさん(2:26)

理由は、オーケストレーション(AIがAIに指示を出して全自動で回す形)の弱点にあります。ゴールが明確な作業なら、全自動で完結する。でも、デザインやUI/UX、オンボーディングに何を足すか、分析結果からどこへ進むかは、いくら知見を貯めても、その時の状況で変わります(2:39)。だから全自動化は、現時点では不可能だと話しています。

束ね役を外した点は、私と近いです。ただ、同じなのは形だけです。

Shinさんは、AIだけでは進む方向を決められない、という理由で外しました。私の運用でも、判断を束ねて別のAIへ回す役は、今は置いていません。私が頼んだ仕事は、1つの担当が受けます。担当の置き方は2段だけで、他のAIへ判断を送って、そこで止まることも禁止です。

私が大事にしているのは、進捗を思い出して催促したり、同じ基準を言い直したりした瞬間に、管理のボールが自分へ戻ってくる、という感覚なんです。

AIの担当が増えるほど、判断の通り道は増えます。通り道が増えるほど、どこで止まったのかが見えにくくなる。束ね役をAIに任せるかどうかより、判断の持ち主を先に決めておくほうが大事だと思います。

02

「1日の意思決定の回数は多分100、200くらい」|1人で答える回し方

図解: 4つの窓から届く確認を、4つの確認と、実行してから報告に仕分ける
動画キャプチャ: オーナー1人のまわりに、経営戦略やAndroidなどのセッションが並ぶ図(3:07頃)
動画キャプチャ: オーナー1人のまわりに、経営戦略やAndroidなどのセッションが並ぶ図(3:07頃)

次は、Shinさんの1日。オーナーが各セッションへ指示を出し、返ってきたレビューに答えます(3:07)。その回数が、1日100〜200回です。同時に回せるのは最大4セッションで、正直4つでも大変、3つくらいがちょうどいい、とも話しています(3:33)。

「だから高速に意思決定をオーナーがやらなきゃいけないっていう状態です。なので僕1日の意思決定の回数は多分100、200くらい。かなりの回数レビューしてC出しして、レビューしてC出ししてっていうのを各セッションでやっています。」

Shinさん(3:07)

この回数を、1人で引き受けている。私の運用とは、ここが違います。

数が多い少ないより、何に答えているかのほうが大事だと思います。動画で数えられているのは、各セッションへのレビューと指示出しの意思決定です。Shinさんを批判したいわけではありません。

私の運用で、AIが確認を出していい場面は、4種類に絞ってあります。公開の最終判断、課金、削除のような戻せない操作、価値観や方針の判断。この4つ以外で迷った時は、元に戻せるなら、実行してから報告してもらいます。

確認を絞る理由は、止まる場面の記事に「止まる場面を増やすほど、任せたはずの仕事が確認待ちで私に戻ってくるからです。」と書きました。

回数は、多いほど仕事をしている気がします。でも、どの確認に答えるかを決めておかないと、どれを手元に残すかも決められません。回数を減らすことと、判断を軽く扱うことは、別の話だと思います。

03

「自分の意思決定を外注して何でもやらせる」|賛成と、AIに任せる範囲・確認する範囲の違い

図解: 本番の扉の手前で、手綱を握って確認する範囲を決める
動画キャプチャ: オーナーと経営戦略のセッションを赤い線で結んだ図(5:17頃)
動画キャプチャ: オーナーと経営戦略のセッションを赤い線で結んだ図(5:17頃)

Shinさんの理由は、二つ。一つは、自分でアプリの状態のコンテキストを持っておかないと、事業全体をコントロールしている感覚が消えて、モチベーションも下がり、意図しない事故も起こること(5:05)。もう一つは、数万人が使う本番に反映する責任です。

「僕は各セッションの全てのレビューは理解して、え、次はこうですよっていう風に返しています。だから自分の意思決定を外注して何でもやらせるってことは僕はやっていませんし、やらない方がいいです。」

Shinさん(5:17)

「なぜなら数万人のユーザーが使っているのに、あの、そこまで外注しちゃったらユーザーさん困るわけじゃないですかね。やっぱりそれを本番に反映したりしちゃったら。」

Shinさん(5:28)

そのうえで、いくら知見が溜まっても、レビューは手放さないことが大事だと話しています(5:38)。

ここは、賛成です。AIに意思決定を外注して、何でもやらせる形は、私もとりません。

Shinさんも、判断の軸を捨てているわけではありません。赤ペンの判例を記録して、次の判定へ渡しています(次の章)。そのうえで、知見が溜まってもレビューは手放さない、と言い切っている。ここが、この動画のいちばん硬い線です。

私は、一件ずつ確認する範囲が違います。私が一件ずつ確認するのは、2章の4種だけ。そのうち戻せない操作は、AI秘書の凛ちゃんが実行の直前で止まって、私の承認を待ちます。それ以外は、実行してから報告してもらっています。確認を減らす方向は、作業のほう。減らさないのは、判断の理由です。

私が自分の判断軸に置いている言葉があります。「魂は渡さないだろ。魂は込めるもの。」手放すのは作業で、目的と判断の軸は、自分で掘るということです。

どちらが正しいか、ではないと思います。何を守るためのレビューか、で分かれます。Shinさんは、本番の責任と事業の手応えを守る。私は、判断の理由を守る。

手放すのは、作業。手元に残すのは、判断の理由!

線引きの1行

AIに渡すと決めた仕事を1つ選び、「これだけは自分が決める」を1行で書く。例は「公開前の最終確認だけは自分」。この1行が、渡す範囲の線になります。

04

「次回の判定が賢くなる」|赤ペンを判例にする

図解: 赤ペンで入れた採用・却下・保留を、判例の帳面に残す
動画キャプチャ: triageの流れ図で、オーナーが赤ペンを入れる段階を示す画面(11:03頃)
動画キャプチャ: triageの流れ図で、オーナーが赤ペンを入れる段階を示す画面(11:03頃)

ここからは、Shinさんが組んだtriage(フィードバックを1コマンドで捌く仕組み)の話です(8:02から)。図の左上には、溜まったフィードバックの数が出ています(累計は、図で500件超、音声で800ぐらい)。指揮役が、それを50件ずつ並列に投げます(9:28)。分類係のtriage-classifierが、バグ・要望・質問・感想に仕分けます。

そこから、バグ調査係のbug-rcaと、要望判定係のrequest-judgeが、同時に動きます。レポートが1本届くと、オーナーが赤ペンを入れます(11:03)。採用、却下、保留に、理由を添える。ここは、オーナー本人の仕事です。

「あ、これ確かに採用だなとかね。あ、これ早く直さなきゃいけないなっていうのはこれは自分でレビューします。」

「ま、ただそのマークダウンにその記録を残していくっていうだけです。」

Shinさん(11:07、後半は11:36)

判例は、docs/decision-log.mdに追記されます。図の表記では、現在112件。要望判定係は、下書きを作るだけで、採否は決めません。

一番まねしやすいのは、ここです!赤ペンを入れて終わりにせず、残す。Shinさんの場合、残す先が判例になります。

私は、フィードバックを、その場だけの条件付きの判断か、ずっと使える判断軸かで見分けます。どの場面で使い、どの場面で使わないかまで言える形にしておく。ずっと使えるほうを、判断メモの1行にします。

訂正を残す考え方は、AIへの訂正の記事に「AIへの訂正は、その場の一言で終わらせない。」と書きました。

私の運用にも、近い形があります。公開する現物は、作った人とは別系統のモデルに検収させる。検収役は、判定して返すだけです。直すのも、採否を決めるのも、作り手の側。要望判定係が採否を決めない形と、役割の置き方が似ています。

検収は万能ではありません。そして公開の最終判断は、私の承認を待つ決まりです。

Shinさんの図では、採用・却下・保留に、理由を添えて残している。この理由が、次の判断の材料になります。

05

「毎回同じミスを繰り返さない」|メモで止まらないなら、仕組みで止める

図解: メモ、毎回読まれる指示書、自動で止める門の3段
動画キャプチャ: セッションからCLAUDE.mdとMemoryへ向かう矢印の図(18:01頃)
動画キャプチャ: セッションからCLAUDE.mdとMemoryへ向かう矢印の図(18:01頃)

次は、図の下にあるCLAUDE.mdとメモリ(17:24から)。CLAUDE.mdは、Claude Codeが毎回読む指示書です。本番に出す前のチェックなど、ルールが溜まるたびに、ここへ保存する。メモリ機能にも、同じように記憶させる。毎回同じミスを繰り返さないために、と話しています(18:01)。

これが、事業を育てることと同じで、学習することだ、と続きます(18:19)。

「自己改善ループとかループエンジニアリングとかグラフエンジニアリングとかなんかかっこいい名前をつけてるんですけども、ま、やってることはもう大したことないっていうね」

Shinさん(18:33)

メモに書くだけでは、同じ指摘が止まりませんでした。書いてあっても、AIが毎回読む場所に無かったんです。

メモを増やす前に、そのメモが毎回読まれる場所にあるか。ここを見ずに足しても、同じ指摘が戻ってきます。Shinさんの図でも、ルールの矢印はCLAUDE.mdとメモリへ向かっていました。読まれる場所へ流し込む形は、私の運用の考え方と重なります。

だから、段を分けています。まずメモに書く。それでも同じことが起きたら、hook(AIの動きの途中で自動で止める仕掛け)へ上げる。

ただし、フィードバックのたびに全部を洗い直すと、学習のためにトークンを燃やす装置になります。だから残すのは、同じ状況で次の判断が変わるものだけです。

判断メモに残す基準は、無人運用の記事に「「今回だけの直しか、これからも使う判断か」。これからも使う判断なら、判断メモに1行足す。」と書いています。

Shinさんの言う「名前に踊らされない」は、ここに効きます。立派な名前の仕組みより、同じミスを2回させない1行のほうが、運用では強いかな。

ルールが死んでいた話の記事にも、「手放すのと、中身を確認しないのは別モノなんです。」と書きました。書いたルールが効いているかは、自分の目で確かめます。

06

「人間が残された仕事」|余白をどう使うか

図解: AIに任せた時間の余白を、人に残す時間に使う
動画キャプチャ: 人間に残る仕事について話している場面(13:24頃)
動画キャプチャ: 人間に残る仕事について話している場面(13:24頃)

triageの話の続きで、人間の仕事に話が広がります(12:03から)。Shinさんの見方では、実装も事務作業も、AIが引き受けています。残るのは上流の意思決定で、それも数年後はAIが担うかもしれない、と話しています。

「人間の仕事っていうのはお金を稼ぐ作業ではなくて、例えば、ま、友達と遊んだりとかなんか旅に出たりとか旅行行ったりとかそれであ、幸せだなっていう風に感じる。ま、その喜びを感じるっていうことが人間が残された仕事だと思うんですよね。」

Shinさん(13:24)

続けて、感情は人間だけが心で感じるもので、AIは表面的に感じるかもしれないが、心では感じられない、とも話しています(13:41)。

Shinさんの言う喜びと、私の判断軸は、向きが同じです。

私の判断軸では、AIが生んだ時間の余白で、人間はワクワク夢中に遊び、探求する。その体験が、原液(自分そのものの濃い中身)と、良いフィードバックになる。それがAIの判断軸と、人間の観を、また育てる。この順番です。

だから私は、遊びを仕事の外に置きません。遊びと探求は、AIを育てる材料の仕入れだと考えています。

AIの外の時間が価値の元になる、という話は、AI共創と休息の記事に「AI共創に価値と意味が出るのは、AIと関係のないところで夢中になっている自分のワクワクに、AIを重ねるからです。」と書きました。

余白の使い道は、AIに聞く前に、自分で決めたい。ここは、人に残したい仕事です!

07

「自分が持ってる知識以上の結果」|Claude Codeという増幅器の限界と、掘る場所

図解: 増幅器を使いながら、人は縦に掘り、AIは横に広げる
動画キャプチャ: パフォーマンスとUI/UX改善のセッションを赤丸で示した図(15:46頃)
動画キャプチャ: パフォーマンスとUI/UX改善のセッションを赤丸で示した図(15:46頃)

次の話題は、Claude Codeで良いアプリを作れる人と作れない人の差(14:30から)。Shinさんは、パフォーマンスやUI/UXの知識があるかどうかだ、と話します。ページ全体を「読み込み中」の文字だけにする、画面にボタンを置きすぎる。そうした例を挙げています。

「AIっていうのはその人の、ま、映しだっていう風にね、言われてはいるんですけども、そうだなと思いますね。ま、増幅期ですよね。やっぱり自分が持ってる知識以上の結果っていうのはなかなか出しづらいという風に思います。」

Shinさん(15:46)

さらに、いくらAIが賢くても、神は細部に宿る、と続きます(16:41)。絵文字をつけるか、びっくりマークで終わらせるか。そうした細部に、センスが出るという例です。

映しで増幅器、という話は、賛成です。AIの出す結果が、渡した側の知識や判断の質で変わる、という点は、私の運用でも同じで、渡し方が雑なら、返ってくる結果も雑になります。

知識が無いと、直すべき所に気づけず、レビューも指示出しもできない。Shinさんは、そうも話しています(15:19)。ここは、Shinさんの言う通りなんです。そのうえで、一つ足したいことがあります。知識がそろっても、何を良しとするかは、自分で決めるしかありません。

人間は縦に掘る。AIは横に広げる。私は、役割をそう分けています。縦に掘るとは、自分が何を良しとするかを、場面ごとに深く確かめること。横に広げる側は、AIが並べて試します。

映しは、自分の判断を確かめる材料にもなります。

知識を増やす努力を、否定するつもりはありません。ただ、調べて埋まる差と、自分で決めるしかない差は、分けて考えたい。

Shinさんは、勉強して、優れた作品に触れておくことが大事だと話しています(16:50)。その触れた体験が、判断の軸の材料になる。私は、そう考えています。

軸がないままAIを使う怖さは、分身AIの育て方の記事に「私がとても怖いと感じているのは、自分の中に軸がないままAIを使ってしまうことです。」と書きました。

Shinさんの言う細部のセンスも、ここに入ります。絵文字をつけるかどうか。その1つを決める理由を、言葉にして残せるか。細部は、勘のままではAIに渡せません!

MATOME

まとめ|意思決定は外注しない。違うのは、一件ずつ確認する範囲

Shinさんの動画から持ち帰ったのは、意思決定をAIに外注しない、という線の引き方です。賛成した点は、全部は渡さないこと。違った点は、一件ずつ確認する範囲。Shinさんは、判断の軸を判例に貯めても、全レビューを自分で見続ける。私は、一件ずつの確認を4つの場面に絞って、軸を手元に残しています。

同じだった点があります。束ね役を外すこと。赤ペンを記録に残すこと。そして、メモに書いたことを毎回読ませること。

AIに任せる範囲はどこまでか。この動画を見て、私の答えは「確認する場面を数えられるところまで」になりました。

今週の宿題(1つ)

今週AIへ出した差し戻しを1件選び、今回だけの直しか、これからも使う判断かに分けます。後者なら、場面・選ぶもの・理由・ただし書きの4点で、CLAUDE.mdに1行足す(書き方は無人運用の記事に書きました)。同じ指摘を2回言ったら、メモから確認待ちか禁止の設定へ上げる。

完了の目安は、次に同じ種類の仕事を頼んだ時、同じ指摘をしなくて済むことです。

COLUMN

ひろくんコラム|立派な仕組みにしない

図解: ひろくんが判断メモに1行だけ書き足している。脇には使わない立派な仕組みの書類の山

AIを育てると聞くと、大きな仕組みを想像します。でもShinさんは、やっていることはMarkdownに記録を残すだけ、と話しています(11:36)。

判断メモの型も、確認待ちから禁止への格上げも、中身は1行の記録。立派な仕組みにしなくていい。それが、この動画から受け取ったこと。

この動画で一番残ったのは、確認を減らす話ではなく、確認する中身を決める話でした。Shinさんは、各セッションのレビューを自分で見る。私は、実行の直前の4つの場面で止まる。数は違っても、人の手元に残すのは判断の理由、という点は同じです。

推測: 1人で回せるかどうかは、AIに任せた量では決まらない気がしています。回せる線引きは、任せる範囲を1行で言えるかどうか。言えないまま広げると、何を確認したのかが、自分でも分からなくなります。

提案です。未実装です。差し戻しを1件受けた時、AIが「今回だけ」か「これからも使う」かを先に仕分けて提案する。私は、最後の1行を決めるだけにする。決めるのは軸のほう。仕分けの手間は渡す、という線引きです。

提案です。未実装です。新しい仕組みを足す前に、いま任せている範囲を1枚に書き出す。足すのは、その後です。

ただし、仕分けが当たっているかを測る方法は、まだ決めていません。

測れないうちは、渡す範囲を広げません。仕分けの「済みました」も、証拠なしでは信じない。この考え方は、分身AI日記の「AIの「完了報告」は証拠がないと信じるな」にも書いています。

日々の気づきは、bunshin-ai.com に書いています。

FAQ

よくある質問

この動画で話しているShinさんは、どんな方ですか?

YouTubeチャンネル「Shin Coding Tutorial」の運営者で、6万人が使うSNSアプリをClaude Codeで開発と運用している、と動画で話しています。「Shinさん」は、チャンネル名からの呼び名です。

8つのセッションとは、何のことですか?

運用体制図で、オーナー1人の周りに置かれた、経営戦略・獲得ハック・フィードバック対応・Android・パフォーマンス・UI/UX改善・多言語対応・モデレーションの8つです。Shinさんは、会社の部署がセッションに置き換わったと話しています。

triageとは、どんな仕組みですか?

届いたフィードバックを、1コマンドで分類してレポートにまとめる仕組みです。AIが50件ずつ並列で分け、オーナーが赤ペンを入れて、その判断を判例として記録します。

「意思決定は外注しない」と、AIに任せることは両立しますか?

両立します。Shinさんは全レビューを自分で見る形、私は一件ずつの確認を4つの場面に絞る形で、どちらも意思決定そのものはAIに渡しません。詳しくは3章に書きました。

CLAUDE.mdとメモリは、どう使い分けますか?

動画では、セッションからCLAUDE.mdに保存することと、メモリ機能に記憶することの、両方が挙げられています。使い分けの基準までは話されていません。5章では、メモが毎回読まれる場所にあるか、という見方を書きました。

動画情報

今回紹介した動画の基本情報です。見たい箇所は、タイムスタンプ付きのリンクから本編へ飛んで、実際の語り口も確かめてみてください。

タイトル6万人が使うSNS開発でわかった、Claude Codeの本当の使い方
チャンネルShin Coding Tutorial
尺20:19
公開日2026年10月1日
動画本編YouTubeで見る
字幕日本語の自動文字起こしで、誤変換があります。引用は字幕の文字のままにしています。
数字の出どころ6万人、8つのセッション、1日100〜200回は、動画での本人の発言です。判例の「現在112件」は、図の表記です。
私の現場の話2026年10月2日時点の指示書と運用の決まりの範囲です。

🎁 無料プレゼント

Aiport(ClaudeCode AIエージェント実践会)

ClaudeCodeでAI秘書+分身AI+AIカンパニーが無料で作れるキット&解説動画をプレゼント!

▶ 無料で入会してキットを受け取る

🤖 AI生成コンテンツについて

この記事はAIツール(Claude Code)を活用して制作しています。構成・文章生成・画像制作にAIを使用し、最終的な内容の確認・編集・公開判断はひろくん(田中啓之)本人が行っています。「分身AIひろくん」(bunshin-ai.com)とは別のコンテンツです。

この記事が気に入ったら、シェアをお願いします

この記事で学んだことを誰かに教えて恩送りして学びを深めよう!

XLINEはてブ

関連記事