#生産性

読んでまず思ったのは、AI導入の話って、やっぱり「使われたかどうか」と「効いたかどうか」をごちゃ混ぜにしやすいんだな、ということでした。 しかも厄介なのは、使われた事実のほうは数字にしやすいのに、効いたかどうかはかなり雑に扱われがちだという点です。ダッシュボードに出るのは usage や token のような見やすい数字で、経営にとって本当に大事な「で、何が増えたの？」は後回しになる。この記事はそこをかなり強く突いていて、読んでいて少し耳が痛かったです。 特に引っかかったのは、saved hours をそのまま saved dollars に変換するやり方への批判です。 たしかに「1人あたり週2時間削減、人数を掛ける、時給を掛ける」は見た目がきれいです。でも、その時間が本当に別の売上や削減につながったのか、あるいは単に少し余裕ができただけなのかで意味は全然違う。そこを曖昧にしたままROIを語るのは、かなり危ないと思いました。 もうひとつ面白かったのは、calendar time と labor time を分けて考えるべきだという指摘です。 「3週間かかっていた機能が1週間になった」と

結論から言うと、どっちでもいい。日本語で書いて全然問題ない。 ネットで「CLAUDE.mdは英語が正義」みたいなの見るけど、あれ半分は雰囲気で言ってるだけだと思う。Claude は普通に日本語の指示を読むし、ちゃんと従う。「英語じゃないと精度ガタ落ち」みたいなことは起きない。 ただ「どっちでもいい」で終わると記事にならないので、ぶっちゃけどこで差が出るのか、正直なところを書く。 CLAUDE.md っていうのはプロジェクト直下に置いとくと Claude Code が自動で読んでくれる指示書ファイル。「このリポジトリではこうしてね」を書いとくやつ。 ここに日本語で「テストは npm test で回して」「コミットメッセージは日本語で」とか書いても、ちゃんと効く。Claude は多言語モデルだから、指示の言語が日本語か英語かで「言うこと聞かなくなる」みたいなことはまず無い。だから読めるか読めないかで悩む必要はゼロ。ここを勘違いして「英語じゃなきゃダメなんだ…」って無理して英語で書くのは、正直いちばんもったいない。 差が出るとしたら、だいたいこの3つ。全部「精度」じゃなくて「

以前のLinuxみたいに、「オープンなものを使う＝仕事で大きく損する」という時代はかなり薄れてきた LLMの世界では、今もClaudeやGPTのような proprietary model（企業が提供する閉じたモデル）が性能面で先行している ただし open models もかなり追いついてきていて、差は「数か月遅れ」くらいだと著者は見る いちばん大きい問題は性能差より、プライバシーと運用の面倒さ ClaudeのID verification（本人確認）導入をきっかけに、「もうオープンモデルへ寄せてもいいのでは」という空気が強まっている 著者は、仕事で使うとしても生産性の落ち込みは短期的で、致命傷ではないと考えている この記事は、タイトルだけ見ると少し過激です。`cancel_claude` という名前だと、Claudeを全面否定する話に見えますが、実際はもっと現実的で、かなり実務寄りの話でした。要するに、「トップの閉じたAIモデルを使わなくても、今なら仕事は回るのでは？」という問題提起です。しかもその根拠が、意外と地に足がついている。ここが面白いところです。 著者はまず、昔のLinux

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