非エンジニアが起業・個人開発でAIに任せる作業と任せない作業の線引き

「非エンジニア 起業」「非エンジニア スタートアップ」と検索してAIエージェントの活用を調べる人が知りたいのは、機能の一覧ではなく「結局どこまで自分の手を離していいのか」という線引きだと思う。この記事では、Claude Codeが権限をどう3段階に分けているかを土台にしながら、非エンジニアが個人開発・起業でAIエージェントに実際に何を任せ、何を任せなかったかを表にする。

3行まとめ

1. Claude Code公式ドキュメントの権限設定は、ツールの使用をallow（確認なしで許可）・ask（都度確認）・deny（拒否）の3段階に分ける仕組みで、これは非エンジニアが自分の作業を任せる範囲を考える時にもそのまま使える枠組みだった
2. 「作る」「検証する」作業は任せやすい一方、「外部に公開する」「課金が発生する」といった取り消せない操作は、既定で人間の実行を挟む設計にしておくと事故が減る
3. 「何を基準に良し悪しを判定するか」という判断そのものは、AIに実装させても中身は人間が決めるべき部分として最後まで残った

土台になる考え方: allow・ask・denyの3段階

Claude Codeの権限設定は、ツールごとの扱いを3段階で分ける仕組みになっている。公式ドキュメントの説明では、allowは「ツール使用を許可する権限ルールの配列」、askは「ツール使用時に確認を求める権限ルールの配列」、denyは「ツール使用を拒否する権限ルールの配列」とされている。機密ファイルを守る設定例として、公式ドキュメントには次のような書き方が載っている。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)"
    ]
  }
}

このように、「何でも任せる」でも「何も任せない」でもなく、①確認なしで任せてよいもの ②都度確認するもの ③そもそも触らせないもの、の3段階に分けて考える発想は、権限設定というシステムの話にとどまらず、非エンジニアが起業や個人開発でAIエージェントに何をどこまで任せるかを考える時の枠組みとしてそのまま使える。

より詳細な公式ドキュメント「Permissions」（curlで確認）を読むと、このallow/ask/denyはツールごとの個別ルールで、それとは別に、セッション全体の動作モードを切り替える仕組みもあることが分かった。

「①確認なしで任せてよいもの」の範囲そのものを、セッション単位で広げたり狭めたりできる設計になっている。個人開発でAIエージェントに任せる範囲を考える時も、「この作業ブロックだけはplan相当（見るだけで実行はさせない）にする」というように、作業の性質でモードごと切り替える発想が応用できる。

もう1つ興味深いのが、Bash・PowerShellの許可プロンプトでCtrl+Eを押すと、そのコマンドが「何をするか・なぜ実行しようとしているか・何が起こりうるか」をモデル自身に説明させ、Low risk・Med risk・High riskの3段階でラベル付けする機能があることだ。「このコマンドは任せてよいか」をAI自身に一次評価させ、最終判断は人間に残す、という設計そのものが、この記事の主題と同じ構造を持っている。

任せてよい作業(allow相当)

実際に触ってみて、確認なしで任せてよいと感じたのは次の作業だった。

これらに共通するのは、失敗しても被害が「やり直しの手間」で済み、外部に影響が出ない作業だという点だ。間違った実装が出てきても、公開前であれば動かして検証する段階で気づける。実際に台本検証ツールをAIエージェントに実装させた記録は非エンジニアがAIエージェントに個人開発を任せてみた実測記録に書いている。

確認してから任せる作業(ask相当)

次に、任せてもよいが「実行の直前で必ず人間の確認を挟む」ようにした作業がある。

自分が組んだツールでは、動画を実際に公開する操作を、既定では実行しない設定にしている。公開したい時だけ、呼び出し側で明示的に指定しなければ実行されない作り方だ。これはaskの考え方を、会話の中での確認ではなくツールの設計自体に埋め込んだ形に近い。

人間に残すべき判断(denyでは代替できないもの)

最後に、AIに実装や実行を任せても、判断そのものは人間に残した部分がある。これはallow/ask/denyのようにツール側で制御できる話ではなく、判断の中身そのものの話になる。

• 何を「正しい」「異常」と判定するかの基準づくり: チェックの仕組みはAIに実装させても、その基準（文字数の許容範囲や、何を危険な数値として扱うかなど）は、実際に失敗した経験をもとに人間が決めた
• 著作権や規約まわりの最終判断: グレーな領域について「実際の慣行としてどこまで許容されているか」を判断するのは、条文の字面だけでは終わらない
• 予算の上限そのものを決めること: いくらまでなら使ってよいかという線は、AIが提案するものではなく人間が先に決めておく前提の話
• 実行結果を「成功」と判定してよいかの最終確認: ツールが正常終了のログを返しても、それが意図した結果になっているかまでは、人間が実物を見て確認するまで確定しない

AI生成コードを本番に出す前に何を確認するかという、より実務寄りの判断基準は非エンジニアがAI生成コードを本番に出す前に見る判断基準に書いている。ビルドで実際に起きた事故の記録は非エンジニアがAIコーディングで事故った話にまとめてある。

この「判断の中身は人間に残す」という考え方は、自分の運用ルールだけでなく、Claude Code自体の公式な設計思想とも一致していた。公式ドキュメント「Security」（curlで確認）はこう明記している。

"Claude Code only has the permissions you grant it. You're responsible for reviewing proposed code and commands for safety before approval."

（訳）「Claude Codeは、あなたが与えた権限しか持たない。承認前に、提案されたコードやコマンドの安全性を確認する責任はあなたにある」。権限を絞る仕組み自体はツール側が用意していても、「安全かどうかを判断する責任」はツールに移譲されない、という位置づけがAnthropic自身の文書にも明記されている。

Anthropicの技術ブログ「Building effective agents」（2024年12月19日）も、近い考え方を示している。

"Agents can then pause for human feedback at checkpoints or when encountering blockers."

（訳）「エージェントは、チェックポイントやブロッカーに遭遇した時点で、人間からのフィードバックを待って一時停止できる」。エージェントに実行を任せる設計そのものの中に、あらかじめ「ここで止まって人間に聞く」チェックポイントを組み込んでおくという発想は、この記事の「ask相当」の考え方と重なる。

まとめの表

ここまでの内容を1つの表にまとめる。

起業や個人開発でAIエージェントを使う時に迷ったら、「これは取り消せる作業か」「これは外部や自分の財布に影響するか」の2つを自問すると、この表のどの段に置くべきかが決めやすい。

この表は固定の正解ではなく、あくまで自分の運用から逆算した現時点の線引きだ。AIエージェントに任せられる範囲は今後も広がっていくはずだが、「取り消せるかどうか」「誰の財布や信用に影響するか」という2つの問いは、任せられる作業の幅が変わっても判断の軸としては残ると考えている。

この線引きは自分1人分の経験則にすぎない

• この表は、私自身がClaude Codeで個人開発・動画制作の検証業務を行ってきた経験から逆算したものであり、他のツール（Codex、Devinなど）や他社のチームでの運用ルールと比較検証したものではない。 allow/ask/denyという枠組み自体はClaude Code公式ドキュメントから確認したが、それを「非エンジニアの作業全般」に当てはめる部分は、この記事独自の解釈である
• autoモードの「分類器がリクエストとの整合性を確認する」という挙動の中身（どのような基準で判定しているか）は、公式ドキュメントの記載をそのまま紹介したのみで、実際に分類器がどう振る舞うかを自分で検証したわけではない
• 「良し悪しの基準づくりは人間に残すべき」という主張自体に、定量的な裏付け（この基準を人間が決めなかった場合に実際にどれだけ事故が増えるかなど）はない。 あくまで自分の運用で起きた失敗の経験にもとづく判断であり、一般化できるかどうかは分からない
• Ctrl+Eのリスク説明機能（Low/Med/High risk）を実際に使い比べて、その判定精度を検証したわけではない。 公式ドキュメントに記載されている機能の存在と概要を紹介したにとどまる