AI 2026年4月23日

AIがコードを書く時代に、エンジニアの仕事が「構造設計」になる理由

𝕏 シェアする

AIがコードを書けるなら、エンジニアは何をすべきか

Qiitaに興味深い記事が上がっていた。タイトルは「AI時代にエンジニアがまだ必要な理由は、コードではなく構造にある」。著者の@Lin-Nikaidoが提示する主張はシンプルだが、刺さる。

エンジニアの仕事はコードを書くことではない。世界を構造化することだ。

これは精神論ではない。AIがコードを生成できるようになった今だからこそ、この視点が実務レベルで問われ始めている、という話だ。

「動く」だけでは不十分、という現実

記事の中に、印象的なコードの比較がある。同じread_message関数を2通りの書き方で示している。どちらも動く。しかし一方は「美しくない」と著者は言う。

「美しくない」ほうのコードは、DBへのクエリ、レコードからオブジェクトへの変換、メッセージの取得……といった処理が一関数の中にベタ書きされている。読めば理解できる。でも、読むのに時間がかかる。

美しいほうは3行だ。verify_user、load_messages、そして内包表記でcontentを返す。何をしているかが一目でわかる。

著者はこう言い切る。「多くのコードは『動く』という条件だけで評価されてしまう。確かに、動くコードは価値を生む。しかし、それは最低条件に過ぎない」。

持続可能なコードの共通点は、苦労せずに読めることだ。大規模OSSのように数千人が関わるプロジェクトが機能し続けられるのも、この読みやすさに支えられている。

そして重要なのが、読みやすさは「意識して書く」ものではない、という指摘だ。美しく設計されたコードは、結果として読みやすい。 実装のテクニックではなく、世界の分割の仕方が先に来る。

OpenableBlackbox——理解を「途中でやめていい」構造

記事で提案されているコンセプトが OpenableBlackbox だ。

Blackboxの価値はよく知られている。コンパイラがどう動くか、CPUがどう計算するかを知らなくても、エンジニアはコードを書ける。詳細を隠蔽することで、理解コストを劇的に下げられる。

ただ、Blackboxには致命的な弱点がある。問題が起きたとき、または修正が必要になったとき、そのBlackboxを開けなければならない。そしてよくある話として——作った人はもういない、開けたらスパゲッティ、ドキュメントは存在しないか古い。

OpenableBlackboxはその解だ。記事中のコード例を見ると直感的にわかる。

@app.post("/createOrder")
def create_order_endpoint(item: CreateOrderRequest):
    return create_order(
        user_id=item.user_id,
        item_id=item.item_id,
    )

このAPIを見た人は、「userとitemに基づいてオーダーを作る」とわかる。それだけわかれば、このAPIを使う実装に移ればいい。ここで理解を止めていい。

もしcreate_orderの中身が気になれば、IDEでCtrl+clickして開ければいい。そこにまた、get_active_user、get_purchasable_item、build_orderという読める構造がある。さらに深く潜りたければ、また開ける。

これがOpenableBlackboxの本質だ。「すべてを説明する」のではなく、「必要なときに開けられる」構造を作ること。理解のグラデーションを設計することがエンジニアの仕事になる。

AIおじさんの見方：AIが「本質」を可視化した

ここで少し立ち止まりたい。

この記事が言っていることは、実は昔から言われてきたことでもある。「良い設計」「単一責任の原則」「可読性の重要性」——どれも目新しい概念ではない。

では、なぜ今これが重要なのか。

AIがコードを書けるようになったことで、「コードを書く」という作業の価値が相対的に下がったからだ。以前は「実装できる」こと自体がエンジニアの競争優位だった。今は、実装の多くをAIに任せられる。そうなると、AIが生成したコードをどう評価し、どう構造に落とし込むか、という上位レイヤーが前景化する。

著者も明確に書いている。「AIがコードを書くようになったとしても、世界の構造を設計する仕事は依然として残る。むしろ、より重要になる」。

これは、少しAIにコードを書かせてみた人なら実感として持てるはずだ。AIは「動くコード」を出してくる。しかし、それをどの関数に配置するか、どのモジュールに切り出すか、どこをBlackboxにしてどこを開けるままにするか——そこはAIに任せっぱなしにすると、あっという間に読めないコードができあがる。

構造設計はエンジニアの仕事だった。AIの登場でそれが「も」エンジニアの仕事になったのではなく、それ「こそが」エンジニアの仕事だったことが、ようやく明確になったという整理が正確だと思う。

実務的な示唆：今日から使える視点

抽象論に終わらせないために、実務的な観点で整理しておく。

1. コードレビューの軸を変える
「動くか」「バグがないか」に加えて、「この関数の責務は一言で言えるか」「このBlackboxは開けられるか」を問うようにする。特にAI生成コードをそのまま取り込む場合は、このチェックが重要になる。

2. 「理解を途中でやめられるか」を設計の評価基準にする
OpenableBlackboxの概念を使うなら、「この関数を見た人が、中を見なくても用途を理解できるか」を問う。関数名、引数名、返り値の型——これらが文脈を伝えていれば、コメントがなくても理解できる。著者は「コードが語る。ドキュメントを書くな、もうコードを書いたじゃないか」とまで言っている。

3. AIへの指示を「実装」ではなく「構造」レベルで出す
AIに「この機能を実装して」と丸投げするのではなく、「この責務をこの単位で切り出して、この関数名で実装して」という粒度で指示を出す。その指示を出せる人間が、AI時代のエンジニアとして差別化できる。