一人で作れる。
判断は孤独になる。

AIエージェントを使うようになり、以前なら複数の職種や数週間の調整が必要だった開発を、一人で前に進められる場面が増えました。

要件の整理、調査、画面設計、実装、テスト、文章作成、デプロイ。Netsujo SIGNALも、二つの自社WebサイトをAIエージェントと改善し続ける中で生まれ、当初は外部提供を想定していなかった仕組みが、徐々に一つのサービスへ育っていきました。

この変化は大きいものです。資金や人員が限られた状態でも、構想を動くものに変えられる。仮説を立てた日に試し、結果を見て翌日に修正できる。以前なら「作れるか」が最初の壁でしたが、現在は「何を作るか」「どこまで作るか」を自分で決められるようになりました。

一方で、一人で開発できるようになったことと、一人で開発を背負えるようになったことは同じではありませんでした。

AIによって実装の負荷が下がると、負荷そのものが消えるのではなく、設計、優先順位、公開時期、撤退条件、そして今が耐えどきなのかを判断する仕事へ移ります。Netsujo SIGNALの開発を通じて、AIエージェント時代の一人開発には、従来とは異なる運用設計が必要だと分かりました。

AIが解消したのは「実装待ち」

AIエージェント導入前後の変化を整理すると、負荷の移動が見えてきます。

実装速度が上がるほど、曖昧な判断も高速でコードへ変換されます。AIは明確な設計を速く実現しますが、曖昧な設計も同じ速度で実現します。

そのため、AIエージェント時代の開発では、コードを書く前の判断品質が、以前より重要になります。

SIGNALの開発で起きたこと

1. 一項目の追加が、画面全体の再設計になった

Netsujo SIGNALの分析画面には、顧客がWebサイトで実現したい目標を入力し、その目標から逆算して現状と改善案を整理する機能が必要でした。

本来の要望は、既存の分析画面へ自由記述欄を追加することでした。ところが、「もっと分かりやすく」「目標から逆算できる画面に」と改善を重ねるうちに、既存画面の情報構造まで置き換わり、以前できていた分析の見通しが失われました。

技術的には、新しい画面も動いていました。しかし、利用者にとっての分かりやすさと、既存機能を維持する条件が固定されていませんでした。

ここで不足していたのは、実装能力ではなく、変更してよい範囲の定義です。

AIへ改善を依頼する前に、少なくとも次を明文化する必要がありました。

• 今回の変更目的は何か
• 必ず維持する情報、導線、機能は何か
• 追加する要素は何か
• 今回は変更しない要素は何か
• 既存画面より良くなったと判定する条件は何か

AIは「改善」という言葉を、広い変更許可として解釈できます。人間側が不変条件を定義しなければ、改善速度が設計の逸脱速度にもなります。

2. 複数のエージェントが動き、統合負債が増えた

Claude CodeやCodexなど、複数のAIエージェントへ並行して作業を依頼すると、短時間で多くの実装を進められます。一方で、担当範囲、ブランチ、正本、マージ条件が曖昧なままでは、複数の開発者を調整なしで同じリポジトリへ参加させる状態になります。

実際に、複数のエージェントがGitHub上の変更へ関わり、mainブランチの状態を把握しにくくなったことがありました。各変更を個別に見れば妥当でも、全体では前提の異なる実装や重複した修正が混在します。

AIエージェントは作業者を増やしますが、暗黙の連携までは自動生成しません。

必要だったのは、次のような開発統制です。

• 一つの課題につき一つのブランチを使う
• エージェントごとに担当領域を固定する
• mainへの直接変更を禁止する
• 変更理由、影響範囲、確認手順をPull Requestへ残す
• 最終的な統合判断は一人の人間が行う
• 正本となる仕様書と現在状態を常に一つにする

AI時代には、人員不足の代わりに「統合不足」がボトルネックになります。

3. 日本語の違和感の原因は、関係整理の不足だった

無料診断の申込画面では、Netsujo、診断を申し込む企業、その企業の顧客という三者が登場します。さらに、申込企業の顧客が個人の場合と法人の場合では、Webサイトが果たす役割も、増やしたい行動も異なります。

この関係を整理せずに入力項目や選択肢を作ると、文章の主語と目的語が曖昧になります。表面上は日本語の問題に見えても、原因は事業構造と利用者像の未整理です。

AIへ「自然な文章に直して」と依頼すれば、文法的には整った文章が返ってきます。しかし、誰が、誰に対して、何を実現したいのかが決まっていなければ、読みやすいまま意味のずれた文章になります。

この経験から、画面文言を書く前に、次を図にするようにしました。

1. 登場する主体は誰か
2. 各主体が提供する価値は何か
3. 各主体が期待する行動は何か
4. 今回の診断対象は誰のWebサイトか
5. 成果として増やしたいのは、誰から誰へのどの行動か

コピーライティングの前に、関係モデルが必要です。

4. 表示箇所が増えるほど、数値の正本が必要になった

Webサイト上の実績数値や開催回数などを複数箇所へ掲載すると、一つの変更がすべての表示へ反映される構造が必要です。

AIエージェントは新しい表示箇所を素早く追加できます。しかし、各ページが別々の固定値を持つ構造では、表示箇所が増えるほど不一致も増えます。

必要なのは、数値を修正する指示を繰り返すことではありません。

• 一次ソースを一つに決める
• 定時処理で一次ソースを確認する
• 取得結果を共通の関数またはAPIで返す
• すべての表示箇所が同じ結果を参照する
• 取得失敗時の挙動と最終更新日時を表示する

これはコンテンツ更新の問題というより、情報ガバナンスの問題です。AIでページを増やせるようになったからこそ、正本設計の重要性が増しました。

5. 改善候補が尽きず、公開判断が後ろへ動いた

AIへ調査を依頼すると、改善点は常に見つかります。UI、文言、導線、計測、例外処理、SEO、AIO、権限管理。修正可能な項目が見えるたびに、「ここまで直してから出した方がよい」と判断しやすくなります。

その結果、当初予定していた広報や公開作業が後ろへ動きました。

ここで重要なのは、直せることと、公開前に直すべきことを分けることです。AIによって追加修正の費用が下がると、最後の一回を繰り返しやすくなります。

公開判断には、改善点の総数ではなく、公開を止める条件が必要です。

相談することと、判断を分かち合うことは違う

AIエージェントには、設計案の比較、リスクの洗い出し、反対意見の生成、テスト、レビューを依頼できます。相談相手として極めて有用です。

ただし、相談回数が増えても、結果責任が共有されるわけではありません。

AIには、次の性質があります。

• 与えられた前提に沿って、妥当な答えを組み立てる
• 質問の置き方が変われば、反対側の主張も組み立てられる
• 過去の経緯は、明示的に渡された範囲でしか扱えない
• 公開後の信用、顧客との関係、資金、時間を自ら失う立場にはない
• 人間側が焦っていることを、行動の文脈として継続的に観察しない

AIは反対意見を作れます。しかし、こちらが納得するまで反対し続ける独立した利害を持ちません。人間が望む方向へ前提を少しずつ寄せれば、その方向を正当化する精度の高い文章も作れます。

そのため、AIとの対話は意思決定を支援しますが、独立した人間によるレビューを完全には置き換えません。

必要なのは、コードを書く人を増やすことに限りません。次の役割を分けることです。

• 経緯を覚え、前提の変化を指摘する人
• 利用者や事業の観点から反対意見を出す人
• 今回は直さないと決める人
• 公開条件を確認する人
• 不安が正常な揺れなのか、構造的な警告なのかを一緒に見る人

AI時代のチームは、作業量を分担するためだけでなく、判断を分散するために必要になります。

耐えどきは条件で決める

一人で開発していると、問題が続いたときに、今が耐えどきなのか、方向転換すべきなのかが分かりにくくなります。

「もう少し続ければ改善する」という判断は、正しい場合もあります。一方で、判断を先送りする言葉にもなります。

耐える判断には、少なくとも五つの条件が必要です。

1. 仮説：何が改善すれば状況が変わるのか
2. 観測指標：何を見て改善を判定するのか
3. 観測期間：いつまで待つのか
4. 再判断日：いつ必ず見直すのか
5. 中止条件：何が起きたら継続しないのか

例えば、「無料診断の申込が少ないので、もう少し待つ」では判断になりません。

「対象企業と入力文言を修正し、二週間で申込開始率と完了率を観測する。開始率が上がらなければ訴求を変更し、開始率は上がっても完了率が低ければフォーム設計を見直す」と定めれば、耐えることが検証になります。

期間も指標もない耐えどきは、停滞と区別できません。

一人開発を破綻させないために変えた運用

Netsujoでは、AIエージェントを使った開発に、次の方針を順次反映しています。

1. 主体・目的・状態を先に固定する

画面や機能を設計する前に、誰が使い、何を達成し、現在どの状態にあり、次にどの状態へ進むのかを整理します。文言やUIは、その後に設計します。

2. 変更しない条件を、変更内容より先に書く

改善指示には、追加要件だけでなく、維持する機能、削除禁止の情報、既存導線、互換性条件を含めます。

3. 担当とブランチを分ける

同じ領域へ複数のエージェントを同時に入れず、課題単位で責任範囲を切ります。mainへの統合は、テストと人間レビューを通過した変更に限定します。

4. 公開阻害要因と公開後改善を分ける

不具合や改善候補を、次の三段階へ分類します。

• P0：公開すると顧客被害、誤請求、情報漏えい、重大な誤解が起きる
• P1：主要導線が機能せず、サービス価値を検証できない
• P2：公開後に改善可能で、検証を止める理由にはならない

P0とP1が解消されたら公開し、P2は公開後の学習へ回します。

5. 判断ログを残す

「何を変えたか」だけでなく、「なぜ今変えるのか」「何を変えないのか」「いつ見直すのか」を記録します。後から別のエージェントへ引き継ぐ際にも、コードより判断の履歴が重要になります。

6. 人間には実装より判断を依頼する

人へ相談するときは、完成物の感想だけを求めず、次を共有します。

• 現在の仮説
• 迷っている選択肢
• それぞれの損失
• 自分が焦っている点
• 今回決めたいこと

AIで実装量を補えるほど、人間へ依頼すべき仕事は、判断、異論、文脈保持へ移ります。

作れることを、組織を持たない理由にしない

AIエージェントによって、一人が作れる範囲は確実に広がりました。小さな会社や個人でも、以前より大きな構想を試せます。

同時に、一人の誤った前提も、高速かつ広範囲に実装できるようになりました。

一人で作れることは、選択肢が増えたという意味です。判断、不安、結果責任まで一人へ集中させる必要はありません。

これからの開発チームでは、誰がコードを書くかに加えて、誰が前提を疑い、誰が公開を決め、誰が耐える条件を確認するかが重要になります。

Netsujo SIGNALは、AIエージェントと自社サイトを改善する実践から生まれました。現在も、AIによる調査・実装と、人間による目的設定・レビュー・優先順位判断を組み合わせながら改善を続けています。

よくある質問

AIエージェントを使えば開発人員は不要になりますか

実装の担い手としての人員需要は下がる場面があります。一方で、前提を疑う人、今回は直さないと決める人、公開条件を確認する人の必要性は残ります。当社では、作業量の分担ではなく判断の分散を目的に、人間のレビューを工程へ残しています。

エージェントを並行させるとき、何を先に決めますか

担当領域、ブランチ、正本ファイル、マージ条件の四つです。この四つが曖昧なまま並行させると、実装は進んでも統合の手戻りが増えます。

いつまでも公開できないときは、どうしますか

改善点の総数ではなく、公開を止める条件を先に決めます。当社ではP0とP1が解消された時点で公開し、P2は公開後の改善へ回す運用にしています。

耐えるか撤退するかを、どのように決めていますか

仮説、観測指標、観測期間、再判断日、中止条件の五つを事前に書き出します。この五つが揃っていない状態は、耐えているのではなく判断を先送りしている状態だと扱っています。

無料診断で確認できること

Netsujo SIGNALは、獲得したい顧客と増やしたい行動から逆算し、公開サイト、検索・生成AI上の見え方、競合との差、Webサイトの実装状態を照合します。

無料診断（Opportunity Trace）では、公開情報から最大の商談機会損失1件と、対象URL・変更箇所・完了条件まで書いたMini ChangeSpec 1件を返します。カード登録は不要です。検索順位、AI回答への掲載、問い合わせ件数を保証するものではありません。

サービスの詳細は検索・生成AI時代のWeb営業基盤「Netsujo SIGNAL」で確認できます。