「楽」を選ぶほど、未来の選択肢は減るのか: 下着とAI開発をつなぐ委任の設計

「楽だから」という理由で選んだものが、あとになって最も高くつくことがある。

それは下着の選び方にも、AIを使ったソフトウェア開発にも共通している。一方には、身体への負担を減らしてくれる便利な選択肢がある。他方には、指示するだけでコードの理解、計画、実装、プルリクエスト作成まで進めてくれる強力な道具がある。どちらも、目の前の手間を劇的に減らす。

しかし、ここで見落としやすい問題がある。負担が消えたのではなく、負担の発生場所が移動しただけではないかということだ。

便利さは、しばしばコストをなくすのではなく、見えにくくする。しかもそのコストは、使い始めた瞬間には現れず、選択を変えにくくなったころに現れる。身体の状態として現れることもあれば、保守できないコード、理解できない設計、判断力を失ったチームとして現れることもある。

この二つの領域をつなぐのは、単なる「便利さへの注意」ではない。より重要なのは、支援と依存の境界をどう設計するかという問いである。

楽な選択は、未来の選択肢を消費する

ある下着は、着けた瞬間には楽かもしれない。締めつけが少なく、調整も少なく、日常の不快感を減らしてくれる。その価値は本物だ。楽であることを悪と決めつける必要はない。

ただし、身体を支えるという役割を考えると、快適さだけでは評価できない。支える力、形を保つ仕組み、身体との相性、使用時間、買い替えのタイミングなど、複数の要素が関係する。目先の快適さだけを基準にすると、未来の状態を維持するための選択肢を知らないまま使い続ける可能性がある。

ここで大切なのは、特定の方式を一律に推奨することではない。身体の特徴も、生活環境も、必要な支え方も人によって異なるからだ。重要なのは、「楽」という一つの指標が、将来のコストを覆い隠すことがあるという認識である。

AIによる開発支援も同じ構造を持つ。タスクを入力すると、AIが要件を読み、実装計画を立て、コードを書き、プルリクエストまで作る。これは単なる補完機能ではない。開発工程そのものの一部を、まとまった単位で委任する仕組みだ。

開発者は、細かな検索や定型コードの記述から解放される。小さな機能を試す速度も上がる。経験の浅い人にとっては、隣に有能なインターンがいるような感覚になるかもしれない。

しかし、便利な自動化には別の問いが伴う。そのコードがなぜそう書かれたのかを、誰が説明できるのか。

AIがコードを書いたとき、コードの生成は速くなる。一方で、設計上の前提、例外処理の意図、依存関係の意味、将来の変更に対する弱点まで理解したことにはならない。生成物が動くことと、チームがそれを所有していることは別である。

便利な道具は、仕事を減らすだけではない。仕事を「見えない場所」に移す。

「右か左か」より危険なもの

選択肢が二つあるとき、人はしばしば自分の選択を正当化するために、もう一方を低く評価する。自分は賢い選び方をした、相手は遅れている、という物語を作ると、判断に自信を持ちやすいからだ。

けれども、自分の選択を肯定することと、別の選択を侮辱することは違う。ある方法を選んだ理由を説明することと、別の方法を選ぶ人を見下すことも違う。

この区別は、AI導入にも決定的に重要である。AIを使わない開発者を時代遅れと呼ぶことは簡単だ。反対に、AIを使う開発者を思考停止と決めつけることも簡単である。どちらも、技術的な議論を身分や人格の議論に変えてしまう。

本来、問うべきなのは「AIを使うか、使わないか」ではない。

・どの作業を委任するのか ・どの判断を人間が保持するのか ・結果を検証する能力をどう育てるのか ・失敗したとき、誰が原因を説明できるのか

これらを問うべきだ。

下着についても同様に、「どちらが正しいか」という対立にすると、個人差や状況が消える。大事なのは、相手を下げて自分を上げることではなく、選択の結果を長い時間軸で観察できることだ。

選択肢を守るためには、選択肢そのものを侮辱しないことが必要である。

ある方法を使う人を笑えば、その方法の弱点を指摘する機会も失われる。批判が人格攻撃に見えた瞬間、相手は防御に回り、改善に必要な情報を共有しなくなる。組織ではこの現象が特に深刻になる。新しいツールを使う人と使わない人が互いに軽蔑し始めると、技術選定は学習の場ではなく、派閥争いになる。

自動化の本当の代償は、能力の空洞化である

便利さが危険になるのは、間違うからだけではない。自分で間違いを発見する能力が失われるからである。

電卓は暗算能力を一部代替するが、計算結果の桁が妥当か確認する感覚まで失う必要はない。自動車は歩行を代替するが、地図を読む力や道路の危険を理解する力まで手放すとは限らない。問題は道具を使うことではなく、道具が出した結果を評価する基礎能力を維持しているかどうかだ。

AIコード生成では、この評価能力を監督可能性と呼べる。監督可能性とは、出力をただ受け取るのではなく、次の三つを判断できる状態である。

1. その出力は、要求を正しく理解しているか
2. その出力は、見えていない条件に対して安全か
3. その出力を、将来の変更や障害に耐えられる形で維持できるか

AIが一度に大量のコードを処理できるようになるほど、この能力の重要性は増す。長大なコンテキストを読み込めることは、理解を保証しない。大量の情報を見られることと、何が重要かを判断できることは別だからだ。

例えば、AIが認証機能を追加し、テストも通ったとする。しかし、権限の境界が曖昧なままなら、テストが通ることは安全を意味しない。データベースの更新処理が一見正しくても、途中で失敗したときに整合性が壊れるかもしれない。コードが動くという事実は、設計が正しいという証明ではない。

これを身体の支え方に置き換えると、短期的な快適さが長期的な状態の維持を保証しないという話になる。どちらの場合も、表面上の評価だけでは不十分だ。必要なのは、現在の快適さと未来の回復可能性を同時に測ることである。

支援と依存を分ける「三層委任モデル」

では、便利さを拒絶せず、依存も避けるにはどうすればよいか。実践的には、作業を三つの層に分けるとよい。

第一層: 反復作業を委任する

形式変換、定型コード、候補の列挙、既存パターンの適用など、失敗しても発見しやすい作業は自動化しやすい。ここでは速度の利益が大きく、監督の負担も比較的小さい。

身体に関する選択なら、着脱のしやすさ、洗濯のしやすさ、日常的な不快感の軽減などがこの層に近い。生活の負担を減らすことは、それ自体で重要な価値である。

第二層: 判断の候補を委任する

AIに設計案を複数出させたり、テストケースを洗い出させたり、既存コードの問題点を指摘させたりする。この段階では、AIは答えを出す存在ではなく、検討材料を増やす存在になる。

ここで人間がすべきことは、最初の案を採用することではない。なぜその案を選び、何を捨てたのかを記録することだ。候補を増やす自動化は、判断を奪うのではなく、判断の質を上げる方向に使える。

第三層: 責任を委任しない

安全性、権限、個人情報、長期保守、身体への影響など、失敗したときの損失が大きい領域では、最終判断を自動化してはいけない。AIに相談することはできるが、承認を丸ごと渡してはいけない。

この層の原則は単純である。

出力は委任できる。説明責任は委任できない。

この原則を守るには、チームに「生成物を読む時間」を残す必要がある。AIで実装が速くなったからといって、レビューを省略してよいわけではない。むしろ生成量が増えるほど、レビューは細部の誤字探しから、設計の意図とリスクの検査へ移らなければならない。

選択を長期戦に戻す

短期的な快適さと長期的な健全性は、必ずしも対立しない。問題は、短期の指標だけで意思決定してしまうことだ。

AI導入を評価するとき、開発速度だけを見ると、導入直後の成果に引っ張られる。そこに次の指標を加えるべきである。

・生成コードのうち、担当者が説明できる割合 ・レビュー後に発見された重大な欠陥の数 ・AIなしでも修正できる人の人数 ・数週間後に変更を加えるまでの時間 ・障害発生時に原因を追跡できるか

同じように、日常の製品選びでも、使用直後の快適さだけでなく、長時間使用時の状態、手入れのしやすさ、サイズや仕様を変更できる余地、専門家に相談すべき兆候を観察することが重要になる。

ここで役立つのが、可逆性という基準である。選択を間違えたとき、簡単に戻れるか。別の方法へ移行できるか。使い続けないと損をする構造になっていないか。

可逆性の高い選択は、積極的に試してよい。可逆性の低い選択は、導入前の検証と導入後の観察を厚くする。AIが書いた小さな社内ツールは比較的戻しやすいが、基幹システムの認証基盤を理解なしに置き換えるのは戻しにくい。この差を見ずに、同じ勢いで自動化を進めるのは危険である。

Key Takeaways

・「楽になったか」だけでなく、「将来の選択肢が残っているか」を評価する。 便利さの裏側に、依存や保守負債が隠れていないか確認する。

・AIには反復作業と候補作成を任せ、責任ある判断は手放さない。特に安全性、権限、個人情報、長期保守に関わる決定は人間が承認する。

・自分の選択を肯定するために、別の選択肢やその利用者を侮辱しない。対立を減らすほど、実際の長所と短所を学びやすくなる。

・定期的に「AIなしで説明、修正、再現できるか」を点検する。できない部分が増えたら、便利になったのではなく、能力の空洞化が進んでいる可能性がある。

・導入前に可逆性を確認する。小さく試し、結果を観察し、戻せる状態を保ったまま利用範囲を広げる。

便利さは敵ではない。問題は、便利さを無条件に善とみなすことだ。身体を支える道具も、コードを書くAIも、私たちの負担を減らすために存在する。だが、負担を減らすことと、判断する力を手放すことは同じではない。

良い道具とは、使う人を不要にする道具ではない。使う人がよりよく観察し、より正確に判断し、必要なときには道具なしでも立てるようにする道具である。

最後に残る問いは、「どちらを選ぶべきか」ではない。

その選択によって、未来の自分は何を選べなくなるのか。

この問いを持てる人は、便利さを恐れずに使える。そして、便利さに使われることもない。