今週から新しい試みとして、毎週水曜日に週報を書いてみる。中身としては、次のことに書いていくつもりだが、そのときの興味・関心によって書く内容は変化するだろう。
- この 1 週間で私自身に起きた特筆すべきできごと
- これは単独の記事として書くので週報になることは稀
- X (旧 Twitter) で話題になったできごと (主にプログラミングに関して)
- AI 関連のニュース
X では、日々 AI 関係のできごとが投稿されているが毎日何かしらのアップデートがあり、それらを追うのが難しいのに加えて直ぐに消費されてしまう。 1 週間もすれば昔のことのように誰も話題にしなくなる。なので、昔の個人ブログの役目によろしくインターネット上であった身の回りのできごとだけでも残していこうという思いだ。
プログラミング
スタッフエンジニアが見積もりを「丁寧な嘘」と断じる記事にエンジニア共感 / X
どうやら海外の記事 How I estimate work as a staff software engineer を発端として X 上で盛り上がっていた。 ChatGPT 5.2 Thinking で日本語で要約すると次のような主張がされている。
- ソフトウェア業界には「熟練したチームなら努力次第で開発期間を正確に見積もれる」という“礼儀としての建前”があるが、著者はそれは基本的に誤りだと置く。結果として、Tシャツサイズ見積もりや「最初の見積もりを倍にしてさらに20%」のような半ば諦めに近い経験則が横行する。
- 見積もりが難しい理由は、開発時間の大半が「事前に分からないこと（未知）」の調査・探索・影響範囲の把握に費やされるから。既知の作業は見積もれても、プロジェクト全体を支配する未知は事前に見積もれない。計画会議で未知を潰し切る発想も、結局“見積もれない部分”を会議側に移すだけで現実的ではない。
- 見積もりは、エンジニアリングの生産性向上のためというより、組織内での意思決定（予算・優先順位・中止）を行うための政治的ツールとして機能しがち。上位者の意向が強い案件では、見積もりが「望ましい数字」に寄せられる圧力がかかることもある。
- 「作業があって、それに必要な期間を推定する」という理解は逆で、実際には“先に期間（期待される見積もり）があり”、その期間に収まるように解法・スコープ・品質・リスクを調整して「どの仕事として成立させるか」を決めることが多い。期限が6か月なら堅牢な実装、1日なら割り切った実装、のように同じ要求でも設計は大きく変わる。
- 著者の見積もり手法（スタッフエンジニアとしての実務的アプローチ）
- まずコードを見る前に政治的コンテキストを集める（どれだけ強い要請か／絶対に間に合わせる必要があるのか／マネジメントが求めているレンジは何か）。
- 「どれくらいかかるか？」ではなく「1週間（など所与の期間）で成立するアプローチはどれか？」と問う。
- 既知の作業より未知を重視し、触る必要のある“暗い森（未踏領域）”が多いほど見積もり（あるいは採用可能なアプローチの制約）を厳しくする。
- マネージャーには「確定期間」ではなくリスク評価として返し、複数案（正攻法だが爆発リスクあり／一部を迂回して期限優先／詳しい別チームの支援を入れる等）を提示してトレードオフを委ねる。
- 反論への応答として、見積もりを拒否して未知が解消されるまでコミットしない態度は、結局「技術的に弱い人が代わりに（より不正確に）見積もる」状況を招きうる、という立場。マネジメントと協働して現実的な妥協点（技術的な取引）を作るのも職能の一部だと述べる。
- まとめ：正確な期間見積もりは原理的に困難。良い見積もりとは、未知の量と怖さを中心に捉え、求められている期間レンジの中で実現可能な複数の計画とリスクを示し、意思決定を可能にすること。
これらの主張を見て思い起こされるのは次の 2 つ書籍だろう。
人月の神話【新装版】
ソフトウェア見積り 人月の暗黙知を解き明かす
まだ、読んだことがない人は是非読んでみて欲しい。『人月の神話』は知名度に対して読まれていない本として有名だと思う。
話を戻すと、この著者の主張について同意する。さらに言うと、見積りが意思決定を行うために機能するのであればまだマシと思う。現実は、実現可能と思われる見積りは無視された上でスケジュールが決まって開発が開始する。そうすると、著者が言っているように「期間に収まるように」諸々の調整が行なわれる。結果とし、最初の見積りであれば開発に当てられていたであろう時間はスケジュールがタイトになったことに対する対応に消費される。本当に不毛でしかない。
AI
Codex でスキルが使えないバグ
Codex の v0.89.0 で REPO スコープのスキル ($CWD/.codex/skills) が読み込まれない不具合が発生している。
GitHub の Issue で報告されており、v0.90.0-alpha.5 で修正されているようなので、今日、明日には修正されると思われる。
Claude CodeのTodosがTasksに進化、大規模プロジェクトの自律管理を実現 / X
Claude Code の Todos 機能が Tasks 機能にアップグレードされた。
Todos 機能では、単純な TODO リストとしてタスク管理がされていたが、Tasks 機能ではタスクの依存関係を考慮するのに加えて、~/.claude/tasks にファイルとして書き出されることで複数のエージェントがタスクを共有することができるようになった。
Skills で実現している人や実現しようと考えていた人は沢山いたと思うが、公式機能として提供されたのは嬉しい。
Claude Codeのベストプラクティス、日本語リソースが開発者コミュニティで広がる / X
後述の Claude Code のベストプラクティスが Anthropic から公開されたのを受けて日本語で学習できる資料が多数公開されていた。
ヤン・ルカン氏、Meta退社理由を明かす「LLM漬け」に批判 / X
これも何度か発信されている主張だ。研究開発が LLM に寄り過ぎており、全く新しい手法に研究リソースが割かれなくなっている実情があるらしい。しかし、既にチキンレースは始まってしまっているので参加している大手テック企業は決着が付くか、レースから降りざるを得なくなるか、本当の限界が見えるまでこの傾向は変わらないと思う。
Claude Code is suddenly everywhere inside Microsoft | The Verge
Microsoft で Anthropic の「Claude Code」を社内で大規模に展開し、Windows／Microsoft 365 など主要チームだけでなく、デザイナーやPMなど非エンジニアにもプロトタイピング目的で利用を促しているといった主旨の記事が公開されていた。エンジニアの間では Claude Code が登場した頃から Anthropic の知名度はどんどん上がっていたが、最近になって Claude Cowork 公開されたのをきっかけに (?) エンジニア以外でも Claude の有用性が広がっているように感じる。
ベストプラクティスを学びやすくするためのサイトを作った人がいたので、公式ドキュメントを読むのが手間 (英語が苦手) な人はこちらから見ていくのがいいだろう。
Clawdbotが話題の個人用AIエージェント PCをスマホから操る / X
Clawdbot という AI エージェントが話題になっていた。 Slack や Discord のようなチャットアプリ経由で AI エージェントにタスクを依頼できるようだ。 Claude Cowork と同じようにコーディングエージェントでできるようになっていたことの民主化だろうか。
気になりはするものの、そもそもこの手のシステムにリソースを回せるほど生成 AI に課金できていない。 Claude も ChatGPT も Pro プランを一瞬で使い切ってしまうし、Antigravity の無料枠も 1 日で溶かしてしまう…。
Claude Code や Codex を使っていない人は試してみた方がいいと思う。
Anthropic CEO「エンジニアはもうコードを書かない、AIに任せ編集だけ」 / X
ここ最近多くの著名プログラマーも似たような発言をしている。 Linux の生みの親として有名なリーナス・トーバルズも生成 AI が生成するコードはゴミと過去に発言していたが、 Linux のコアではなく補助的なツール開発でコーディングエージェントを活用していると言っている。
また、Node.js の開発者である Ryan Dahl も「人がコードを書く時代は終わった」と言っている。
This has been said a thousand times before, but allow me to add my own voice: the era of humans
writing code is over. Disturbing for those of us who identify as SWEs, but no less true.
That's not to say SWEs don't have work to do, but writing syntax directly is not it.
— Ryan Dahl (@rough__sea)
January 19, 2026
他にも有名なプログラマーが似たような発言をしていたと思ったがロストしてしまった。そうならないための週報のはずなのに….。
これらの発言は基本的にはポジショントークとしての側面があるものの、人がコードを書く時代は本当に終わってしまったと思う。コード規約やコード品質が、という主張をする人がいるが Agent Skills を整備すると人間がやるよりもアーキテクトの思想を組み取ったコードを出力してくれるし、初回に吐き出されるコードの品質も自由に調整できる。ただし、Claude Opus 4.5 以上のモデルを使うという前提ではある。
故にこれからのプログラマーに求められる能力は、単なるコーディングではなく、
- ドメイン知識をコードレベルに落とし込むための抽象的な判断力
- コードレベルでのアーキテクチャ
- 単一責任の原則や高凝集・疎結合を始めとする保守性を向上させるコーディングにおける原則の適用
といったコーディングエージェントが現時点ではデフォルトで備えていない能力を補助することだと思っている。 LLM が与えられたプロンプトに対して場あたり的なコードを初回の生成では出力することが多い。そのため、その後の軌道修正、コード品質の向上へ向けた舵取りを行わなければならない。そう思わない人もいるかもしれないが、体感としてはこの作業を怠ると制御不能になると感じている。この意見に対して否定的な人は、文字通り Vibe Coding を実践しているか、無意識の内にこれらの反映したプロンプトを実践しているかのどちらかだろう。
人がコードを書く時代は終わったというのは概ね同意する。これは、先日執筆した『リニューアル』のポエム部分でも触れている。しかし、現時点ではコーディングが取り上げられると本当の意味で思えるのはコーディングを単なる作業と言い切れるところまでコードを書いた人に限るのではないだろう。コードを書かない人がどうやってコードの善し悪しを判断する能力を手に入れられるのだろうか。新卒でコンサルタントになった人が何をコンサルできるのか、という話と似ているように感じる。コンサルは先輩の仕事を見て学べばいいのかもしれないが、プログラミングの場合、成果物はもはや人が作ったものではなくなっている。コードを書かずにコーディングに纏わるあれこれを学べるかには疑問があるが、これはもう古い考えなのかもしれない。
この話は長くなりそうなのでこの辺にする。
Claude Code公式ベストプラクティスが公開され開発者で話題 / X
Claude Code 公式がベストプラクティスを公開した。目新しいものではなく、Anthropic がこれまでにブログや公式ドキュメントで主張している内容や X で不特定多数の人が発信しているプラクティスをまとめるとこうなる、というのを公式が公開したという位置付けだろうか。 Claude Code を始めとするコーディングエージェントを日常的に使っている人は、経験則として会得していた内容が多いと思う。それがちゃんと言語化される形で提供されたので、他の人にナレッジとして共有するのが楽になったのは助かる。
デジタル庁のオープンソース定義にコミュニティから強い反発 / X
デジタル庁がまた辺なことを言っているようです。どうして日本は既存の言葉に間違った意味を与えてしまうのだろう。
OOPとFPのプログラミング議論が再燃、開発者たちの熱いやり取り / X
OOP、FP で盛り上っていた。X 上でこの手の話題が上がるのは何回目だろう。毎年 3, 4 回は同じ話題が繰り返されていないか？
そもそも言語と指向、シンタックスと意味論を区別していない人が多すぎる。みんなメタ言語、メンタルモデル を獲得してくれ。話はそれから。
Google Geminiが大学入学共通テストで無料モード839点の高得点を記録 / X
X のニュースでは Gemini がタイトルになっていたが、GPT-5.2 Thinking は 15 科目中 9 科目で満点を取ったという報道がある。選択問題なので LLM と相性がよいというのもあるが、共通テストレベルの問題であればほとんどの日本人より LLM の方が選択問題で良い点を取る時代となってしまった。 LLM を使ってコーディングをしている身からすれば、普段の実装力を見れば共通テストで高得点を取るのは不思議ではない段階まで来ているのは不思議ではないと思った。
今週ではないけど…
Code Is Cheap Now. Software Isn’t. — Chris Gregori
この記事は面白そうなので読んでから感想を書く。
おわりに
初回ということもあり、思っていたよりも文量が多くなってしまった。週報なので日曜日にまとめて書いているが、日次で執筆自体はした方がいいと今回は学んだ。書いたり、記憶を頼りにソースを探すのに時間もかかってしまったので反省。
