#業務効率

小型モデルの値付けがここまで露骨に攻めてくると、「安いから軽い仕事向け」という単純な見方だけでは済まなくなってきたな、と思った。要約や分類、サブエージェント向けと聞くと地味に見えるけれど、実際の現場ではそういう雑務がいちばん数を食う。そこを90％減で押しにくるのは、性能競争というより、AIを“使える回数”の勝負に持ち込んでいる感じがある。 一方で、記事を読んで少し引っかかったのは、安さの話がかなり前に出るわりに、Anthropic自身が複雑なエージェント型コーディングではSonnetやOpusを推している点だった。つまり、Haiku 5.5は「何でもこなす小型モデル」ではなく、「大量処理を安く回すための歯車」にかなり割り切っている。ここをはっきり線引きしているのは誠実でもあるし、逆に言うと、現場での役割分担がもう前提になっているのだろう。 あと、10万トークン以下の利用が大半だったから大幅に下げられる、という説明はかなり実務っぽい。理屈としてはもっともだけれど、長文を丸ごと投げる使い方をしていると恩恵が薄くなる。モデルの賢さだけでなく、使い方の癖まで料金に反映される時代になってきたんだ

AI coding agents が開発現場に入ると、コードはたしかに増える。だが、出来上がるソフトウェアの量まで増えるとは限らない。Ars Technica が取り上げた最新の研究は、そのズレをかなりはっきり示している。AI が生む効率は、結局のところ人間の review に吸い取られてしまうのではないか、という話だ。派手なデモや「開発が何倍速くなる」といった宣伝に慣れた目から見ると、かなり冷ややかな結果に見える。 記事が紹介しているのは、Harvard University の Fiona Chen と James Stratton による研究だ。ふたりは Jellyfish の集約分析データを使い、実際のソフトウェア開発現場で AI coding tools が何を変えたのかを追った。対象になったのは、2021年から2026年3月までのデータで、700社超、70万人超の従業員にまたがる情報だという。データの中身もかなり広く、300 million 件の individual work events、たとえば commit や pull request に加え、issue 管理ソフ

読んでまず思ったのは、こういう比較で本当に差が出るのは「正解率」ではなく、仕事の途中で人間がどう感じるかなんだな、ということだった。両方ともテストを全部通っているなら、勝負は出力の速さや、どれだけ背景まで掘るかに移る。そこがいちばん面白いし、同時に少し厄介でもあると思う。 ChatGPTのほうが速い、Claudeのほうが丁寧、という結果は直感に合う。けれど実際の業務だと、速いほうがありがたい場面と、説明が厚いほうが安心できる場面はかなり違う。たとえば急いで答えがほしいときは前者が勝つし、判断の根拠を追いたいときは後者のほうが助かる。つまり「どちらが優秀か」より、「どの瞬間にどちらを使うか」の話に見える。 一方で、ここまで同じ精度なら、最後の差が説明量で決まるのは少しおもしろい。AIの評価ってつい“当たったか外れたか”に寄りがちだけど、実際には納得感や読みやすさもかなり大きい。人間相手の仕事では、答えそのものより、その答えを受け取るときの疲れにくさが効くことがあるからだ。私はそこに、この比較記事のいちばん現実味があると思った。 --- > 参考: [Claude's merged cha

AIモデルはチャットには向いているのに、実務の自動化になると急に頼りなくなる。TypeSafe AIはその違和感に真正面から答える形で、System One Modelsと初の公開モデル「Jev」を発表した。この記事は、ただの新製品発表というより、「LLMの次に何を作るべきか」をかなり強い言葉で言い直した宣言に近い。読みどころは、彼らが何を捨て、何を機械向けの新しい標準にしようとしているかだ。 TypeSafe AIの創業者Diogo Almeidaは、元OpenAIの研究者として、言語モデルを指示に従わせ、人と会話できるようにする方法づくりに関わってきたという。その流れがChatGPTにつながった一方で、彼は「モデルはチャットでは超人的でも、なぜ自動化はまだ十分広がっていないのか」という問いを抱え続けていた。そこで同社は、2年のステルス期間と多くの技術課題を経て、System One Modelsという新しいクラスのフロンティアモデルを打ち出した。目的は、ソフトウェアがそのまま使える高速で構造化された判断を返すことだ。 最初の公開モデルがJevで、早期アクセスとして提供されている。T

まず思ったのは、「性能が倍」と聞いても、現場の仕事では案外わからないものなんだな、ということだった。この記事でいちばん面白いのは、Claude Fable 5.1 と Fable 5 を実際の仕事にかけてみて、どちらもきれいに答えは出したのに、体感ではほとんど区別がつかなかった点だと思う。 これ、かなり示唆的だ。AIモデルの改善は、ベンチマーク上では派手に見えても、実務では「同じように賢い」以上の違いとして現れないことがある。しかも今回は、難しいタスクでは新しいモデルのほうがトークン消費、つまり課金量がむしろ大きかったという。速くなった、賢くなった、という広告文句だけでは、実際のコスト感までは見えない。そこがかなり気になる。 もう一つ引っかかったのは、エージェント的な作業、つまりAIに調査や手順の実行をかなり任せる使い方では、「できるかどうか」より「どれだけ無駄なくやるか」のほうが重要になってきていることだ。回答精度が同点なら、次に見るべきは速度でも知性でもなく、結局は料金と再現性になる。この記事はその現実を、かなり冷たく、でも正直に見せているように感じた。 AIの進化って、つい新モデ

まず思ったのは、「やっとか」という感覚だった。LLMがWebページを見て作業する流れは、もうかなり前から当たり前になりつつあるのに、毎回Chrome拡張に寄せていたのは少し不自然だった。デスクトップアプリの中にブラウザが入ると、道具としての一体感が出る。小さな変更に見えて、使い勝手はかなり変わるはずだと思う。 ただ、ここで面白いのは「ブラウザを持った」こと自体より、どこまで本気でWeb操作を肩代わりさせるつもりなのか、という点だと思う。ブラウザがあると聞くと、つい“なんでもできる”感じがするけれど、実際にはログイン、権限、動的に変わる画面、CAPTCHAみたいな面倒ごとが残る。AIにページを読ませるのは簡単でも、Webをちゃんと使わせるのはまだ別問題だ。この記事を読んで、その境界線がむしろ気になった。 一方で、拡張機能に頼らなくてよくなるのは、導入の心理的なハードルを下げる。企業の端末ではChrome拡張の許可や管理が面倒なことがあるし、ブラウザ依存が減るのは運用上かなりうれしい。こういう「技術的には派手じゃないけど、現場では効く」改善は、AI機能の価値をじわっと押し上げるんじゃないか

まず思ったのは、これはかなり小さい話に見えて、実はかなり大きい問題だということです。 `AGENTS.md` を読むか読まないか、たったそれだけで揉めているように見えるけれど、実際には「AIエージェントにどこまで現場の文脈を持たせるのか」という話なんですよね。 Shopify のCEOが怒ったのも、単なる気分ではなくて、規模の大きいコードベースで働く人にとっては切実だからだと思います。人間の開発者なら、リポジトリの説明ファイルやチームのローカルルールを見てから作業するのは当たり前に近い。でも Claude Code のようなツールがそこを読まないと、毎回「このツールには手順を口頭で教え直す」ことになる。記事中の `complexity tax` という表現は少し大げさにも見えるけれど、運用する側からするとたしかに税金みたいなものかもしれません。便利さのはずが、使うほど説明コストが増えるのはいやな感じです。 もうひとつ引っかかったのは、Anthropic 側がその要望をすでに閉じていた、という点です。ユーザー側の不満がはっきり出ているのに、製品の設計として優先されていない。このズレは、A

Claude Codeに、アーティファクト（Artifacts）対応が入った。これ、地味に見えてかなり面白い機能です。なぜなら、AIとのやり取りって、本人には見えていても周りからは見えにくいからです。「いま何を調べているのか」「どこまで進んだのか」「途中経過をみんなでどう確認するか」。そのモヤモヤを、Claude CodeがWebページとして“見える化”してくれるわけです。 Claude CodeがArtifactsに対応し、作業進捗をWebページとして表示できるようになった 対応環境はClaude Code CLIとデスクトップアプリ 当初はTeam/Enterprise向けのベータ提供だったが、後にPro/Maxにも広がった 生成されるページは、プルリクエスト解説、デバッグタイムライン、システム図、ダッシュボード、チェックリストなどに使える URLは固定で、チーム内で共有するとリアルタイム更新される バージョン履歴も残り、必要なら過去の版に戻せる 7月15日追記で、共有や共同編集にも対応。Slack経由で使うこともできる Claude Codeを使ったことがある人ならわかると思いま