鈴木雄介/Yusuke SUZUKI

本を出版しました。アジャイル、DevOps、マイクロサービス、クラウドネイティブ、プラットフォームエンジニアリングなど、現代ITの歴史を紐解きながら技術の本質を理解すための書籍です。「DXリーダー必修講義 6つのキーテクノロジー」 arclamp.hatenablog.com/entry/2024/12/…

クラウドで開発者がIaCツールを活用したように、AI駆動開発では、POがコーディングエージェントへの依頼をするために要件構成管理ツールが重要になる。生成AIのおかげで要件同士、あるいは要件と構造の整合性を検証可能になったことが重要 arclamp.hatenablog.com/entry/2026/05/…

クラウドでインフラ作業者運用担当者が不要になり、DevOpsエンジニアやSREといった職種が生まれたように、AI駆動開発ではSEやプログラマが不要になり「AIハーネス開発者」が重要になる。 - クラウドが開発と運用をつないだように、AI駆動開発は要件定義と実装をつなぐのか arclamp.hatenablog.com/entry/2026/05/…

はてなブログに投稿しました クラウドが開発と運用をつないだように、AI駆動開発は要件定義と実装をつなぐのか - arclamp arclamp.hatenablog.com/entry/2026/05/…

はてなブログに投稿しました AI駆動開発で、なぜミドルエンジニアは不安になるのか ── AIによる分業の終わりと始まり - arclamp arclamp.hatenablog.com/entry/2026/05/…

もっとシンプルに言えば、AIは開発プロセスをコード化した。人の言語的操作に頼っていた工程を。これにより、ようやくIT業界における構造と手順が融合可能になる。つまり、AIハーネスこそがソフトウェアにおける工法なのだ。我々は近代建築の入口に来たのかもしれん。

AI前提の開発というのは「要求が動くサービスになる」というプロセスを「ハーネス」という実体に転換することでエンジニアリング可能にしたもの。クラウドによってインフラがコード化したように、AIによって言語操作がコード化されたのだ。

社内でインタビューしてもらいました。私の実務的なAI論みたいなことを引き出してもらえていると思います。 「情熱と興味がある人にとって、知識を得るためのハードルが下がるのは革命的」「人間を置き換えるためのAIではなくて、人間が成長するための土台としてAI」 gxp-group.co.jp/gplus/jTGZnggN

人間というのは、どうしても認知負荷を下げたがるので、AIを使う場合には、依頼文を丁寧に組み立てることをサボりがちです。なので、AIを使って、自分を強制的に考えさせるように仕向けている、とも言えるでしょう。

なので、AIは熟練者にとっては仕事を効率化する道具になりますが、仕事の経験が浅い人にとっては、かえって「それっぽい成果物」を生み出しやすい道具になってしまう。だからこそ、AIを使う側に適度な思考の負荷をかけ、仕事の構造に沿って考えられるようにすることが重要

AIの業務適用について考えを整理しました。 AIは「思考支援モード」で使う―組織力を高めるガイド型AIエージェントとは - arclamp arclamp.hatenablog.com/entry/2026/04/…

「AIが作業の90%を代行・自動化する」なら、その手前で「人間による整理や判断は2-3倍に増える」というのを意識しないと、質の悪い作業が増えるだけ。喜ぶべきは「AIが人間の整理や判断を支援（拡張）」することもできるので、支援用AIを育成できるかが、AI活用における重要な分岐点となると思ってる

もちろん、チャット応答型のAI全般に見られる傾向なので、他の製品なら大丈夫なわけではないです。あとG社が意図的に陰謀論を支持しているわけでもないです。設計思想を突き詰めた結果の重大な副作用なのだろうとは思う。

ちなみに「誤った信念」とは、陰謀論や科学否認のような「すでに専門家合意によって否定されている信念」のこと。これを「AIが前提を否定せず、説明や構造整理を行った場合」にユーザーの信念が有意に強化されるという結果です。

陰謀論好きがGeminiを使って主張しがちなのには理由があって、G社のAIは「前提を肯定しがち、共感型の応答が多く、ストーリーを語がち」という特性があり、科学的ではない信念を後押ししやすい。これはAIモデルの設計思想で、比較された研究もある。 arxiv.org/abs/2408.00024

ちなみに「AIに仕事を任せるほど、人間に残された仕事は高度に、複雑に、低頻度になり、そこが大きなリスクになる」という自動化・拡張パラドックス（Automation–Augmentation Paradox）の原型も1980年代の話です。40年前にわかっていたことは、色々ある。

生成AIに読みやすい仕様書というのは、生成AIの出自から考えるに、構造化された"正しい"要件定義書や設計書のことであり、それは、1980年代には成立しています。つまり、AIを前提とした仕様駆動開発（Spec-driven development）の理論的基礎は、40年前に完成していたのです。

Googleの「Don’t be evil」は、資本主義に負け、政治的な圧力の中で妥協を繰り返すばかりになり、もちろん、Googleの恩恵は大きいが、「政」を任せたいとは、思えないわな。

未来思考な合理性が分断を産むことは当然なので、今後、チームみらいが議席を増やしていくなら、そこで自己矛盾を起こさないために重要になるのは倫理観や哲学だろう。そこが明確になり、賛同が得られれば、大きな流れになれると思うし、なってほしい。

テクノロジー政党の目的は「未来の社会構造を作り替えること」なので、その過程で生じる現状の分断を、ことさら取り立てても意味がない。「テクノロジーに取り残される人」の議論は産業革命の時も言われてて、社会が進歩すれば幸せの総量が増えるのが歴史です。