0. 5秒結論
【実話】物理作業でもソフトウェアでも、基本姿勢は同じだった。「自分が実行者である必要がない工程は、適切な人・AI・サービスに渡す」。ただし、できないから丸投げしているわけではない。物理作業は普通にできるし、技術領域も検索しながらなら到達できる。問題は時間である。エラー一発で6時間溶けるなら、そこをAIに食わせたほうがいい。
1. 表面だけ見ると「何もやりたくない人」
【実話】簡単な片付けやゴミ出しなど、本人でもできる物理作業を地域の人へスポットで依頼する。一方、裏では大量の記事を多言語で処理し、Markdown/GitHubを使った記事工場のような仕組みを動かしている。
この落差がひどい。
表：「これ運ぶのめんどい。誰かお願い」 裏：「生成→匿名化→多言語化→QC→保存→公開フローを整備」
能力の高低というより、労力を投入する対象の選別が極端なのである。
2. 「全部できる職人」ではなく「完成状態を握る社長」
【実話】CloudflareやGitHubの細かな操作・技術用語は本人もほとんど説明できない。実装はCodex等のAIに大きく依存している。
だから技術者から「Cloudflareは何を使っています？」「デプロイは？」「フレームワークは？」と聞かれても、「知らん。なんかつながってる」が発生し得る。
しかし、何を作りたいか、何を正常状態とするか、何が欠けているか、どこをQCしたいかは握っている。役割としては熟練工よりプロダクトオーナー／社長に近い。
「実装方法は知らん。でも12言語そろってないからやり直し」
この会社、社長の技術説明は弱いが検品だけ妙に厳しい。
3. ゴミ捨てとWeb開発が同じ構造だった
ゴミ捨てなら、必要なのは「何を、いつ、どの状態まで、いくらで頼むか」。実際に運ぶ人は本人でなくてもよい。
Web開発なら、「こういうサイト・フローにしたい」「ここは自動化」「ここはQC」「失敗したら止める」という完成条件を決め、実装はAIへ渡す。
共通する上位ループはこうだ。
目的設定 → 要件化 → 実行主体を選ぶ → 成果を確認 → NGなら戻す
人間かAIかは下位工程の違いにすぎない。
4. 「インフラがないと生きていけないよー」……本当に？
【実話】会話ではネットミームを踏まえて「インフラがないと生きていけない」というネタが出た。
ただし、実態は少し違う。スマホがなくても生存はできる。ゴミも自分で捨てられる。片付けもできる。技術領域も検索すれば進められる。
つまり「能力がなくて不可能」ではなく、インフラが消えると摩擦係数が爆上がりするのである。
インフラ停止後： 「生存不能！」ではなく 「うっっっざ……自分でやるか」
この差は大きい。
5. 技術領域も「できない」ではなく「時間が溶ける」
【実話】CloudflareやGitHubを今すぐ説明・操作する技能は薄いが、検索しながらなら自力で到達できるという認識だった。
従来の手動ルートは、 検索→公式ドキュメント→用語検索→試行→エラー→エラー検索→別解→再試行、 となる。
そして最悪なのがデバッグである。
実装30分。 エラー発生。 検索。 違う。 試す。 別のエラー。 環境、設定、権限、コード、外部サービスのどこが悪いか分からない。 6時間経過。 原因：「設定1文字」。
笑えない。だが、ある。
6. プロでもデバッグは仕事の大きな部分
【一般化】ソフトウェア開発ではバグ調査や保守に相当な時間が使われることが知られている。調査によって比率は異なり、「全員が毎回6時間」ではない。しかし、原因の再現・切り分け・診断が実装そのものより長くなる現象は珍しくない。
重要なのは、コードを書く速度だけではない。
到達可能性 ≠ 到達コスト
自力で最終的に解けるとしても、6時間かかるなら、30分で探索空間を狭められるAIには大きな経済価値がある。
7. AIの価値はタイピングより「探索空間の圧縮」
AIコーディング支援を「コードを速く書く道具」とだけ見ると、この使い方を取り逃がす。
【実話からの一般化】本人にとって大きいのは、ログ、設定、関連ファイル、依存関係を横断しながら、原因候補を絞って修正・検証ループを回せること。
つまり価値の中心は、
コード生成 < 原因探索・切り分けの圧縮
になり得る。
ゴミ捨てを外注して自分の時間を買い戻すのと、エラー探索をAIへ渡して6時間を買い戻すのは、実は同じ発想である。
8. ただし「AIがあるからバグらない」ではない
むしろバグは前提で考える。
工程が増えるほど、単体では正常でも境界で壊れる。生成、整形、多言語、ファイル操作、GitHub、ビルド、配信――接続点が増えれば故障モードも増える。
したがって設計思想は、
バグをゼロにする → 非現実的 バグを検知する → 重要 影響範囲を限定する → 重要 原因を切り分ける → 重要 修正後に再発をテストで潰す → 重要
となる。
9. 一番怖いのは「成功した顔をしたバグ」
派手に落ちるエラーは、ある意味やさしい。止まったことが分かるからだ。
怖いのは、処理が正常終了したように見えて、中身だけ間違っているケース。
「12言語完成！」→11言語しかない。 「リンク生成成功！」→リンク先が一部違う。 「保存成功！」→古い記事を上書き。 「公開成功！」→一部ロケールだけ壊れている。
大量処理では、人間が全部読むより、件数、構造、必須要素、リンク、出力先などを自動検査し、異常だけ止めるほうがスケールする。
10. だから記事工場にQC・監査・ゲートが増える
【実話】記事工場では、単純に文章を作るだけでなく、QC、監査、ゲート、リンク検証などを組み込む方向へ発展してきた。
これは潔癖だからではなく、大量処理では「絶対ミスしない」より「ミスしたら検知できる」ほうが重要だからである。
人間もAIもバグる。外部サービスも落ちる。仕様も変わる。ならば失敗しない世界を祈るより、失敗を捕まえる工場にする。
11. 結論：「できるか」より「自分でやる価値があるか」
このスタイルを「何もできないから外注」「AI依存だから自力ゼロ」と説明するとズレる。
より正確なのは、
できる／調べれば到達できる ↓ でも時間・注意・探索コストが高い ↓ 自分が実行者である必要があるか判定 ↓ なければ人・AI・サービスへ渡す ↓ 自分は目的・条件・検品を握る
という構造だ。
物理世界では人間APIを呼ぶ。 ソフトウェアではCodexを呼ぶ。 本人は社長席で完成条件を握る。
そして全部のインフラが落ちたら？
「生きていけないよー」ではない。
「めんどくせえええええ！！ 自分でやるか！！」
たぶんこれが一番正確である。
