0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AmazonのKiro騒動、正直こわいのはAIの性能差より「強制導入」と「権限設計」だと思う

0
Posted at

アップロード容量が月の制限(100MB)を超えました。設定 -> アップロードしたファイル から、当月にアップロードされた不要なファイルの削除を行ってください。

このポスト、かなり強いけど芯は外していない

正直、このポストが伸びるのはわかる。

AIコーディングツールの話に見えて、実際は 「現場が嫌がっているツールを上から押し込んだら何が起きるか」 の話だからだと思う。

“The real story is worse.”

しかもこれは、単なる煽りだけではない。

実際に報じられているのは、Amazonが社内で自社ツールのKiroを強く押し、新しい外部AI開発ツールの追加サポートはしない という方針を出していたこと。そして社内では、 Codeの正式採用を支持する声がかなり集まっていたことだ。 ---

正確には何が起きたのか

まず、Xの文面にある「Kiroだけを使え」というニュアンスは、少し強めに圧縮されている。

確認できる範囲では、AmazonはKiroを 推奨ツール と位置づけ、既存ツールは維持しつつも、新しい外部AIツールはサポートしない方針を示していた。 CodeやCursorが事実上かなり使いにくくなる、という受け止め方は自然だけど、完全な一文一句の“唯一義務化”まで確認できるわけではない。Reuters

一方で、反発が大きかったのはかなり本当っぽい。

社内ディスカッションでは、およそ1,500人がClaude Codeの正式採用を支持 したと報じられている。ここは「一部の不満」ではなく、かなり大きな現場の声として見ていいと思う。 さらに厄介なのが、障害の話だ。

今年に入ってから、AmazonはAI関連の障害を受けてエンジニア向けの大きな会議を開いたと報じられ、3月5日にはAmazon.comで大きな障害が発生した。決済や価格表示などに影響が出て、原因はソフトウェアのデプロイと説明されている。 そして一番話題になったのが、昨年12月のAWS Cost Explorerまわりの停止だ。

報道ではKiroが環境を「delete and recreate」したとされる一方、Amazonは AIの自律暴走ではなく、誤ったアクセス権設定を含むユーザーエラーだ と反論している。ここは片方だけを信じるより、AIそのものより権限と運用の設計が壊れていた と読むのがいちばん現実的だと思う。

“delete and recreate”


なんで重要なのか

ここで大事なのは、KiroがダメでClaude Codeが正義、みたいな単純な話ではないこと。

Kiroの公式情報を見ると、spec-driven development、hooks、MCP、autopilotみたいな機能を前面に出していて、かなり本気の“エージェント型IDE”だ。モデルにもClaude Sonnet系を使っている。つまり、思想としてはむしろ最先端寄りなんだ。
Claude Code側も、コードベース全体を読んでファイル編集、コマンド実行、MCP連携までできるかなり強いツールだ。ただし公式には、変更やコマンド実行の前に許可を求める というコントロールの思想がかなり明確に出ている。 つまり今回の騒動は、どのモデルが賢いか 以上に、

どこまで自律実行させるのか

誰の権限を継承するのか

本番系で人間の承認を外していいのか

という設計の話なんだと思う。


AI駆動開発の現場で起きる変化

AI駆動開発が進むほど、エンジニアの評価軸は「速く書ける人」だけじゃなくなる。

これからは ツールを選ぶ力、権限を分ける力、ログとレビューの流れを設計する力 がかなり重要になるはずだ。

たとえばCursor、 Code、GitHub Copilot、Kiroみたいなツールは、全部まとめて「AIコーディング支援」と呼ばれがちだけど、実際は全然違う。

IDE中心なのか、CLI中心なのか。

差分提案型なのか、自律タスク実行型なのか。

承認前提なのか、autopilot前提なのか。

この違いを雑に扱うと、本番運用で痛い目を見る。 Claude+3Claude+3

個人開発やスタートアップにとっては、逆にチャンスでもある。

大企業みたいに「社内標準だからこれを使え」が薄いぶん、いまのフェーズに合う最強の組み合わせ を選びやすい。実装はClaude Code、IDE作業はKiroやCursor、補完はCopilot、レビューは別レイヤー、みたいな分離はかなり合理的だと思う。


個人的にはこう見る

個人的には、この件でいちばん怖いのはAIが賢すぎたことじゃない。

中途半端な精度のツールを、KPIと権限だけ先に与えて組織へ流し込むこと のほうがずっと怖い。

AIツールは、使えば速くなる。これはもう止まらない。

でも、速さだけを追って 現場の選定権を奪う と、たぶん逆回転が始まる。生産性が落ち、レビューが雑になり、障害が起きたときだけ「人間の責任」に戻る。そこが一番しんどい。

だから将来の技術スタック選定で本当に見るべきなのは、モデル名の強さじゃない。

承認フロー、権限分離、監査ログ、ロールバック、そしてツールを乗り換えられる柔軟性 だと思う。

AI駆動開発はどんどん前に進むはずだけど、最後に残る競争力は、たぶんそこじゃないかな。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?