個人開発でAIエージェント的な自動化を作った時にやったこと

「個人開発でAIエージェントを作る」と聞くと、人手を介さず完全に自律で動く仕組みを想像しがちだ。しかし筆者が実際にこのサイト(AI時短ラボ)の「ツール広場」で組んだのは、そこまで自律的ではない。投稿を受け付け、保留状態で止め、承認するかどうかは今も人間(筆者)が判断している。この記事では、実際に動いている自動化の範囲と、あえて自動化しなかった部分を分けて記録する。

• 「ツール広場」(ユーザーがAI製ツールを投稿できるページ)は2026年7月11日深夜に本番稼働し、投稿→保留→承認→公開→いいね→コメントという一連の流れを実装した
• 自動化したのは「承認されるまで投稿を非公開にする」「いいねの重複を機械的に弾く」といった機械的な判定。承認そのものは人間が最終判断している
• Claude Code公式ドキュメントによると、hooksは「特定の時点で自動実行される処理」、サブエージェントは「独立したコンテキストで動く専用のAIインスタンス」と役割が分かれている。全自動にするなら両方を組み合わせる必要があるが、筆者はまだそこまで踏み込んでいない

作ったもの: 投稿を承認制で公開するツール広場

このサイトには、ユーザーが自作のAI製ツールをURLで投稿できる「ツール広場」がある。投稿されたツールは、そのままでは公開されない。まず「保留(pending)」の状態で止まり、承認されて初めて一覧に表示される。この一連の流れ——投稿受付、保留中は全経路から非表示、承認後の公開、いいねの重複排除、コメントの投稿と承認——を、Claude Codeを使って実装した。2026年7月11日深夜に本番環境で、投稿から承認・公開・いいね・コメントまでの一連の動作を実際に確認している。

実装にあたって、ログイン機能つきの認証基盤を新設する案もあったが採用しなかった。投稿するたびにアカウント登録を求めると、それだけで投稿の障壁が上がると判断したためだ。代わりに、既に使っていたインフラ(キー・バリュー型のデータストア)の上に承認制の仕組みを組み、ログイン不要のまま投稿できる形にした。個人開発では、機能を追加するたびに新しい基盤を持ち込むより、今あるものの上で組める形を優先した方が、検証すべき範囲が広がりすぎずに済む。

どこを機械的なルールに任せたか

自動化した部分は、判断ではなく「機械的に確認できること」に絞っている。

• 保留中の投稿を、一覧・検索・詳細ページのどこからも見せない: 人間の承認前は、どの経路からアクセスしても表示されないようにルール化した
• いいねの重複排除: 同じ人が同じツールに何度もいいねを押せないよう、機械的に弾く処理を入れた
• 不正な操作の後始末: テスト目的で投稿を作り、却下(reject)した後にデータが残らないよう掃除する処理

これらは「はい/いいえ」で機械的に判定できる範囲であり、人間が毎回考える必要がない部分だ。自動化した部分と人間に残した部分を並べると、次のようになる。

どこを人間の判断に残したか

一方で、投稿を承認するかどうかの最終判断は自動化していない。承認は、管理者だけが使える鍵を使って承認用のAPIを呼び出す形で行っており、その鍵を渡すかどうかを筆者自身が決めている。実務上は、Claude Codeのセッションで「保留中の投稿を確認して」と頼み、内容を一緒に確認したうえで承認の実行を代行してもらう、という運用になっている。つまり判断は人間、実行の手間だけをAIに任せている状態で、完全な自律エージェントとは言えない。

Claude Code公式のhooksリファレンスによれば、hooksは「Claude Codeのライフサイクルの特定の時点で自動的に実行されるユーザー定義の処理(シェルコマンド・HTTPエンドポイント・LLMプロンプトのいずれか)」と定義されている。ツールの呼び出し前後や、セッションの開始・終了といったタイミングで発火する仕組みだ。今回の運用でこの仕組みをまだ本格的に使っていない理由は単純で、「承認するかどうか」という判断自体を機械的なルールに落とし込めていないからだ。悪意のある投稿の判定は、単純な文字列マッチでは誤判定が出やすく、個人開発の検証時間ではその誤判定を洗い出しきれないと判断した。

公式ドキュメントを読み直すと、実は「全部を自動判定にする」以外の中間的な選択肢も用意されていることが分かった。PreToolUseフックは、ツール呼び出しに対してallow(許可)・deny(拒否)・ask(ユーザーに確認を求める)・defer(後で再開できるよう保留する)の4通りの決定を返せる、と説明されている。つまり、明らかに問題のある投稿だけをフック側で機械的にdenyし、判定がグレーな投稿はaskでこれまで通り人間の確認に戻す、という三段階の設計は、仕組みとしては既に用意されている。今回まだそこまで実装していないのは、「機械的にdenyしてよい基準」自体を筆者一人でどこまで安全に定義できるかという、判定基準側の検証の問題であり、hooksという仕組み自体の機能不足ではない。

ただし今回、deferという4つ目の選択肢を自分の運用にそのまま使えるかを確認しようとして、制約に気づいた。公式ドキュメントには「deferはClaude Codeを非対話モード(-pフラグ)で動かしている場合にのみ有効で、対話セッションでは警告を出して無視される」と明記されている。筆者が普段使っているのは対話型のClaude Codeセッションで、「保留中の投稿を確認して」と都度頼む運用なので、このdeferは今の運用形態にはそもそも適用できない。使えるのはallow・deny・askの3択で、「三段階の設計」と書いたのはこの3つを指す。またaskによる確認は、権限プロンプトを省略する「autoモード」（Anthropicの表現では、人間の代わりに別のモデル＝classifierがアクションを審査する仕組み）を使っていても表示され続けると説明されており、hookのaskは自動化の度合いを上げても人間の目を外さない設計になっている点も確認できた。

全自動にするなら何が要るか

Claude Code公式のサブエージェントのドキュメントでは、サブエージェントは「独立したコンテキストウィンドウを持つ専門特化したAIインスタンス」と説明されている。これを使えば、たとえば「投稿内容を一次チェックするサブエージェント」を作り、明らかに問題のある投稿だけを機械的に弾き、グレーな判定だけを人間に回す、という二段構えにできる可能性はある。ただし、そのサブエージェントの判定基準自体を、個人開発者一人で検証しきれるかどうかが次の課題になる。判定を任せる範囲を広げるほど、その判定が間違っていないかを確認する作業も増える——という構図は、個人開発でAIコーディングツールを選ぶ判断基準で書いた「検証しきれる範囲」の話と同じだ。

公式ドキュメントをさらに読むと、サブエージェントは「会話履歴も、これまで呼び出したスキルも、Claudeがすでに読んだファイルも見えない、まっさらで独立したコンテキストウィンドウから始まる」とも明記されている。つまり「投稿内容を一次チェックするサブエージェント」を実際に作るなら、「何を問題のある投稿とみなすか」という判断基準を、筆者の頭の中にある暗黙の勘ではなく、そのつどサブエージェントへの委任メッセージとして明示的に言語化して渡す必要がある。これは前段で触れた「機械的にdenyしてよい基準を定義できるか」という課題と同じ形をしていて、サブエージェントを挟んでも、判断基準を明文化する作業そのものは避けられない。なお同じドキュメントには、会話全体を引き継ぐ「fork」という別の呼び出し方も用意されており、独立した文脈で判定させたいのか、これまでのやり取りを踏まえて判定させたいのかによって、使い分けの余地があることも分かった。

hooksを使ってルールの遵守そのものを機械的に強制する具体的な実装は、AIに「ルールを読め」は効かない──読むまで作業をブロックする仕組み（hooks）の作り方で扱っている。

公開前にAIレビューでどれだけ見つかったか

自動化の仕組みを組んだあと、公開前にもう一段AIによるレビューを挟んだ。実装した処理を別のAIセッションにレビューさせたところ、14件の指摘が出て、うち重大度の高いものが10件あった。内容は、いいねの重複排除に使っている識別情報(フィンガープリント)を偽装される余地があった点、いいね数の加算処理が同時アクセスで整合性を崩す可能性があった点、投稿を却下した際にデータの状態が中途半端に残る余地があった点などだ。これらはいずれも修正した上で本番稼働させている。1人で書いたコードを1人でレビューすると見落としが出やすいというのは、個人開発でAIエージェント的な仕組みを作るときに特に効いてくる問題で、実装したAIとは別のセッションでレビューさせる一手間が、実際に指摘を拾えた実例として残っている。

運用中に気づいたこと

本番稼働の初期に、投稿直後は保留一覧の取得結果が空で返ってくる事象が2回あった。数分待つと自然に解消し、データが消えていたわけではなかったため、書き込みと読み取りの間に時間差がある一時的な現象だと考えている。原因を完全には特定できていないため、再発した場合は使っているデータストアの整合性の設定を見直す必要がある、という状態で記録に留めている。

この記事で「自動化」と呼べる範囲

厳密に言うと、今回作ったのは「エージェントが自律的に判断する仕組み」ではなく、「機械的に判定できる部分を先に済ませ、人間の判断が要る部分だけを残す仕組み」だ。個人開発で自動化を組むときは、最初から全部を自動化しようとせず、まず機械的に判定できる部分とできない部分を仕分けるところから始めるのが現実的だと感じている。

空リストの原因は特定できておらず、これは1サイトの運用記録である

• 前段で書いた「投稿直後に保留一覧が空で返る」現象は、本記事執筆時点でも根本原因を特定できていない。使っているデータストアの整合性モデル(書き込み直後の読み取り一貫性)を疑っているが、それを裏付ける形での再現・検証はできておらず、推測の域を出ない
• PreToolUseフックのask決定を使えば三段階の承認フローを作れるという記述は、Claude Code公式ドキュメントの一般的な仕様の確認であり、筆者が実際にこの構成を投稿承認フローに実装して検証した結果ではない。実装した場合に「機械的にdenyしてよい基準」をどこまで安全に定義できるかは、依然として未解決の課題として残っている
• ここに書いた内容は、筆者が運用する1つのサイトの1つの機能についての記録であり、他の個人開発者が同じ構成で同じ結果になるかは確認していない
• 「AIレビューで14件中10件が重大」という数字は、この1回のレビューで得られた結果であり、AIレビューが一般にどの程度の見落としを拾えるかという統計的な傾向を示すものではない