#自動化

著者は、AI coding を使っていると「人間なら即クビ」レベルの妙な挙動に何度も遭遇したが、それでも利用をやめるどころか、さらに使い込むようになった。 この記事の中心テーマは、AI にコードを書かせるときは code review 以上に test process が大事 だ、という主張。 その根拠として、著者は昔働いていた CPU 設計会社 Centaur のテスト文化を紹介する。そこでは、手書きテストより fuzzing や random testing を重視し、unit test はほぼ使わず、専任の test engineer がいた。 著者は、AI 時代の開発でも「人間が全部レビューする」より、「大量の自動テストで叩く」ほうが現実的で、しかも強いと考えている。 ただし、これは単なる理想論ではなく、実際にバグを見つけて直してきた現場の感覚から来ている。 本文を読んでまず面白いのは、著者の出発点がかなり変わっていることです。AI coding を「便利な補助輪」ではなく、かなり攻めた実験装置として見ています。しかも、その最初の印象がすごい。バ

AIが「仕事をどこまで代わりにこなせるか」を測るとき、だいたい話がふわっとしがちです。 でも今回のZDNETが取り上げた話は、かなり手触りがあります。Anthropicのモデル「Fable 5」が、フリーランスの実務をどれだけ自動化できるかを測るベンチマークで新記録を出したのです。とはいえ、だからといって人間の仕事を置き換えられる段階かというと、答えはまだ「いいえ」です。 Fable 5が、フリーランス作業の自動化性能を測る指標で16.1%を記録した これは過去の記録を大きく上回り、AIの仕事代行能力が急速に伸びていることを示す ただし、16%は100%ではないし、実運用には品質確認やセキュリティなど別の壁がある 人間の評価者をAIに置き換える実験は失敗していて、AIがまだ苦手な領域もはっきりしている 仕事の種類によっては、AIが数分で終えるものもあれば、今も手が出ないものがある この話、数字だけ見ると「AIすごい」で終わりそうですが、私はむしろ「AIの得意・不得意がかなり具体的に見えてきた」のが面白いと思いました。夢物語ではなく、かなり現実的な話です。 今回の中心にあるのは、CAIS

Claude Code を使うとき、つい「いいプロンプトを書けば何とかなる」と考えがちです。私もその感覚はよくわかります。1回きりの質問なら、それで十分なことも多い。でも、同じような作業を何度も回す、途中の結果を確認する、前回の状態を覚えておく、となると話は変わります。そこで必要になるのが、単発の指示ではなく「loop」という考え方です。 元記事は、Youssef Hosni氏が Medium の Level Up Coding に書いたもので、Claude Code を使った agentic automation、つまり「AI にある程度の自律性を持たせて作業を進める仕組み」をどう設計するかを扱っています。面白いのは、AI をいきなり全自動にするのではなく、まずは安全で नियंत्र可な形で回し、少しずつ賢くしていく発想にあると思います。 この記事の主題は、Claude Code を「1回答えるAI」ではなく「繰り返し動く仕組み」として使うこと loop は、実行のきっかけ、読むべき文脈、できること、検証方法、状態の保存場所、停止条件まで含めて設計する 最初は `TASK.md`、

GLM-5.2は、中国のZ.aiが出したopen-weightモデルで、AI研究者や開発者の間でかなり強い反応を呼んだ。 特にcoding harness（AIにコードを書かせる実運用の枠組み）に入れたときの「使える感じ」が大きく、単なるベンチマーク上の数字以上のインパクトがあった。 著者Nathan Lambertは、これは「オープンモデルでも本当に最前線級のagent体験を出せる」と示した転換点だと見ている。 価格競争、open model経済圏の拡大、そして規制や安全保障の議論にも波及しそうだと指摘している。 個人的には、性能そのもの以上に「これで十分仕事になる」と感じる人が増える瞬間が本当に怖くて、同時に面白いところだと思う。 この記事でNathan Lambertが言っているのは、GLM-5.2は「ちょっと良くなった新モデル」ではなく、オープンモデルの見方そのものを変える出来事だ、という話です。 最初はいつもの版番号アップに見えます。GLM-5.1の次なら、せいぜい順当な改善だろう、と。ところが実際には、かなり多くの人が使ってみて「これ、もう普通に強いじゃん」となった。ここが

Googleが2026年6月に公開した記事は、かなり重要です。というのも、Gemini 3.5 Flash に computer use が標準機能として組み込まれたからです。これまで computer use は Gemini 2.5 の専用モデルとして提供されていましたが、今度はメインの Flash モデルに内蔵された、という話です。 地味に見えて、これはかなり大きい。 AI が「文章を返す」だけでなく、画面を見て、理由を考え、クリックや入力まで行う方向へ、実用のレベルで一歩進んだ感じがあります。個人的には、ここは生成AIの見え方が変わる節目だと思います。 Googleの説明をかみ砕くと、Gemini 3.5 Flash に「computer use」という道具が最初から入った、ということです。これを使うと、AI エージェントを作る人たちが、ブラウザ、モバイル、デスクトップをまたいで動く自動化を組みやすくなります。 ここでいう AI エージェントは、単に質問に答えるAIではありません。 「このサイトを開いて、必要な項目を探して、フォームに入れて、次の画面に進

AIエージェントにインフラ運用を任せる。言葉だけ聞くと、かなり未来っぽいです。サーバーの増減、設定変更、障害対応の一部までAIが自動で回してくれる。人手不足の現場には、たしかに夢があります。 ただ、The New Stackの記事が強く押し出しているのは、その夢の前提条件です。AIが賢いかどうかより先に、インフラのデータが正確かどうかが勝負になる、という話でした。ここを外すと、便利どころか事故の温床になる。これはかなり現実的で、そして地味に重要な指摘だと思います。 AIエージェントによるインフラ運用は、まだ「魔法」ではない いちばん危ないのは、各チームにデータが散らばっている状態 間違ったインフラ情報をもとに自動化すると、障害につながりやすい NetBox Labsは、インフラ情報を「信頼できる台帳」のように整える役割を担う AIに任せるほど、最後はデータの品質と検証が大事になる 記事の軸にあるのは、NetBox Labsの考え方です。NetBoxは、ネットワーク機器やIPアドレス、接続関係など、インフラの情報を整理して管理するための仕組みです。ざっくり言えば、**「この機器は

AI導入を「人員削減の手段」として使うのは、短期的には効いても長期的には危ない 会社の本当の資産は、作業そのものではなく、現場の知識や文脈理解にある AIは人を置き換えるより、人の判断力を増幅する道具として使うほうが強い 経験あるチームを維持したままAIを組み込む企業のほうが、結果的に競争力を持ちやすい これからの問いは「何人減らせるか」ではなく、「人の時間をどこまで取り戻せるか」だ 今回紹介する元記事の主張は、かなりはっきりしています。 「AIを理由に人員を減らす会社は、最終的にAIをうまく使った会社に負ける」という話です。 この意見、かなり挑発的です。けれど、読んでいくと単なる感情論ではなく、わりと筋が通っています。 というのも、AI導入の現場でありがちな発想があるからです。 > AIができるなら、この仕事はいらない > じゃあ人も減らせるはず 一見、合理的です。会計上もわかりやすい。給与コストが下がれば、短期的には「効率化しました」と言いやすい。 でも記事は、そこで削られているのは仕事ではなく、実は会社の知識そのものだ、と警告してい