powered by TechFeed
表示モード
Deep Dive

AWSエンジニアが警告する「AIスロップ」問題 — ノリでAIに任せる開発から、仕様書を先に書く開発へ

9月15日、Digit.inが「Developers need to stop shipping AI slop: AWS' Darko Mesaros explains how」と題した記事を公開した。この記事では、AWSのDarko Mesarosが「AIスロップ(AI生成の粗悪なコード)」を避けるための実践的なアプローチについて詳しく紹介されている。

9月15日、Digit.inが「Developers need to stop shipping AI slop: AWS' Darko Mesaros explains how」と題した記事を公開した。この記事では、AWSのDarko Mesarosが「AIスロップ(AI生成の粗悪なコード)」を避けるための実践的なアプローチについて詳しく紹介されている。


AIが量産する「それっぽいコード」の問題

「オンラインで見かけるAIスロップ(低品質コンテンツ)と同様に、ソフトウェア開発にもAIスロップが存在する」——AWSのDistinguished Developer AdvocateであるDarko Mesarosはそう指摘する。

AI生成アプリには視覚的な特徴がある。同じレイアウト、同じグラデーション、同じREADMEファイル。ただし問題は見た目だけではない。AIが生成したコードが意図通りに動くかどうかを開発者が確認しなくなっている点にある。

Mesarosはこれを「モデルの問題ではなく、プロセスの問題だ」と断言する。その処方箋としてAWSが提示するのが、**Kiro** と、新たに公開されたオープンソースツールキット「Kiro Crew」だ。


「スペック駆動開発」を復活させる仕組み

Kiro Crewは、自律的なAIエージェントを「チームメイト」として組み込んだオープンソースのワークスペースだ。その核心にあるのがスペック駆動開発(spec-driven development)——要件定義書・設計書・タスクリストをコードを書く前に作成するという、古くからのベストプラクティスだ。

なぜ多くの開発者がこのステップを飛ばすのか。答えは単純で、面倒だからだ。

「要件定義書を書き、設計書を書き、タスクリストを書く。それは非常に面倒で難しい。開発者としては、すぐにコードを書きたくなる。でもAIがあれば、スペック駆動のプロセスが楽になる」——Darko Mesaros

Kiroはプロンプトからこの3種類のドキュメントを自動生成し、そのドキュメントを「契約書」としてコード生成の指針に使う。「これはKiroが何を作るかについての、開発者とエージェントの間の契約だ」とMesarosは表現する。

さらにKiroは、元記事によればシンボリックAI(記号処理ベースの従来型AIと説明されている)と言語モデルを組み合わせ、要件に対する検証ステップを追加するという。設計書から生成されたテストコードとも連動する仕組みで、「ただLLMがMarkdownを書いて読み返すだけではない」とMesarosは強調する。

「ソフト削除かハード削除か」——仕様の曖昧さが高コストのバグを生む

Mesarosが挙げる具体例が鋭い。要件に「ボタンを押すと削除される」とだけ書いてあった場合、ソフト削除(論理削除)なのかハード削除(物理削除)なのかは不明だ。この曖昧さがコードに固定化されると、後から直すコストが跳ね上がる。スペック駆動開発はこうした問題を、最初の一行が書かれる前に潰す。


バイブコーディングは「やめろ」とは言わない

スペック駆動を推す立場のMesarosだが、近年広まっているバイブコーディング(ノリと勢いでAIに任せてコードを生成する手法)を否定はしない。

「バイブコーディングは有効な選択肢だ。素早くプロトタイプを作るには最高の方法で、できる限り試すべきだと思う。ただ、機密情報やセキュリティが絡み始めたら、それがきちんと動くか確認する必要がある」——Darko Mesaros

判断軸は「コードのブラストラジアス(blast radius)」——そのコードが現実にどれほどの影響を与えるかだ。資金・認証情報・ユーザーデータが絡む領域では、バイブコーディングの結果を慎重に精査する必要がある。

コスト面でも、スペック駆動開発には利点がある。「スペックが固まっていれば、ワンショットで生成できる。ループを何度も回してトークンを消費するより安上がりだ」とMesarosは言う。


開発者の役割の再定義

Mesarosはエンジニアのあり方についても踏み込む。

「開発者の役割は、コードを実際に打ち込む人ではなく、複数のエージェントをオーケストレーションして高品質なコードを生み出す人になった。そして、プロジェクトをAIスロップに対して堅牢にする責任も開発者にある」

実践的なアドバイスとして、Mesarosは次の点を挙げる:

  • エージェントを従来の開発ワークフローに無理やり押し込まない。エージェントに合わせてワークフロー側を最適化する。
  • ローカルテストをできる限り先に実施する(シフトレフト)。テストを後回しにしない。
  • エージェントにはプロジェクトとともに、どう貢献するかの「スキル」も渡す。

こうした考え方は、すでに実際の企業でも採用が始まっている。AWSによれば、株式取引プラットフォームDhan、医療プロバイダーPristyn Care、フィンテック企業Analytics FoxおよびGlimmertechがKiroの構造化ワークフローを導入し、プロトタイピングを加速させているという。いずれもインドを拠点とする企業であり、スペック駆動の恩恵を受けた具体例として元記事で紹介されている。

最後にMesarosが引用したのは、2017年のトランスフォーマーの起源論文「Attention Is All You Need」だ。元記事によれば、Mesaros自身がこのダジャレ的な引用を用いて講演を締めくくったとされており、「GPTの『T』はトランスフォーマーの略だ。そして2026年の今、AI時代に開発者として成功するために必要なのも、まさにアテンション(注意を払うこと)だ」と述べたという。AIに任せっぱなしにして関心を持たなければ、良いものは生まれないという主張は、AIツールが氾濫する現在のエンジニアリング現場に向けたシンプルな警告だ。


詳細はDevelopers need to stop shipping AI slop: AWS' Darko Mesaros explains howを参照していただきたい。