Claude Fable 5で生産性が2倍になった話——半年184日の作業ログから

6月、私の1日あたりのアウトプットは平均18人日分でした。7月、主戦モデルをClaude Fable 5に切り替えたら、36人日になりました。ちょうど2.0倍です。

「1日18人日」の時点で意味がわからないと思うので、順番に説明します。この記事は、2026年1月1日から7月14日までの半年間・184日分の作業ログを全部人日換算した実測データの話です。合計は2,824人日、人月に直すと約141人月（1人月=20人日換算）。システム開発の見積もりで「141人月」と言ったら、20人のチームで7ヶ月かかる規模です。それを半年、1人で回しました——正確に言えば、実行はAIが担い、私は指揮と裁定と検証を担いました。この数字はその総量です。そして、AIへの指示はほぼすべて声で出しています。

先に断っておくと、これは公式ベンチマークではなく、個人の運用1例の観測記録です。だからこそ、数字そのものより先にどうやって測ったかを書きます。

自己紹介

近藤政貴と申します。Guide Inc. VietnamというベトナムのIT企業でCEOをしています。金融系の大規模システム開発（仕様書、実装、監査、見積もり）が本業で、そのかたわら音声入力アプリ koedesk と、ドキュメントホスティングのOSS guidebook を作り、最近は つむぎのAIニュース というAIニュース番組の毎日更新も始めました。

以前の記事にも書きましたが、私は kondo-daily-ops というプライベートリポジトリを起点に、日々の業務のほぼすべてをClaude Codeと一緒に回しています（業務でのAI利用は、所属組織として契約・管理しているサービスの範囲で行っています）。そして作業した日は、必ずその日のログを残す運用を2026年1月1日から続けてきました。半年間の暦日195日のうち、稼働ログのある日は184日。丸一日休んだのは11日だけでした。今回の数字は、その184日分のログが原資です。

どうやって測ったか

自己申告の「頑張った」には何の価値もないので、測定は次の手順で行いました。

1. 日次ログ: 各日の作業ログには、対応したチケット、書いたコード、投稿したコメント、検証結果が、コミットハッシュや投稿IDつきで記録されています(そうなるようにClaude Codeを運用しています)
2. 換算ルーブリックの固定: 「1人日=その領域の実務経験がある熟練エンジニアの8時間」と定義し、作業種別ごとの目安(調査つきのチケット回答=1〜2人日、複数ファイル+テストの機能実装=2〜5人日、など)を先に文書化
3. Sonnet 184体による日別採点: 1日1体のAIエージェントにルーブリックを配布し、担当日のログを読んで「証拠のある作業のみ」を項目別に人日換算。私的な作業は除外、疑わしきは低く
4. 較正: 最終日(7/14)については、Fable 5本体が艦隊とは別に独立して見積もった値(32〜40人日)と艦隊の採点(35.5人日)を突き合わせ、バンド内で一致することを確認

保守的に振れるよう設計しています。実際、ある日の採点エージェントは「ログに記載のないコミットが約15件あるが、規模が不明なため計上しない」と報告してきました。つまりこの数字は、下振れ方向の見積もりです。

限界も正直に書きます。ログは私的リポジトリなので第三者は検証できません。採点はAIによる推定であって、タイムカードではありません。採点AIはログ本文（モデル切り替えの記述を含む）を読める状態で採点しており、ブラインド化されていません。採点者も較正者も、効果を主張する対象と同じClaudeファミリーです。それでも「184日×固定ルーブリック×証拠ベース」の積み上げは、モデルの進歩を実務側から観測する一次データとして出す価値があると考えて、限界ごと公開します。

月次推移

月	人日/稼働日
1月	9.8
2月	13.2
3月	11.2
4月	14.9
5月	15.0
6月	18.0
7月(〜14日)	36.0

1月から6月までのおよそ1.8倍は、後述する「型」の蓄積です。月ごとの上下動（3月は落ちています）を挟みながら、半年かけて効いてきました。

そして7月の2.0倍は、数日で起きました。

7/1  20.75   ← 6月の延長線
7/2  26.5    ← この日から主戦モデルをFable 5に切り替え
7/3  42.5    ← 段差
7/8  50.25
7/9  56.0    ← 半年間の最高記録

偶然できていた「用量反応」実験

ここが一番面白いところです。実はFable 5のリリースは6月上旬で、私は6/10と6/11の2日間だけ先行して使っています。この2日の採点は34.75人日と42.0人日——1ヶ月後の7月平均(36.0)を、その時点で先取りしていました。その後しばらく常用できない期間があり、私の数字は元の水準に戻り、7月2日に主戦モデルとして常用を始めてからは高止まりしています。

• 6月のFableを使わなかった日の平均: 16.3人日
• 6月のFableを使った2日: 34.75 / 42.0人日
• 7月(常用): 平均36.0人日

使った日だけ跳ね、使わない日は戻り、常用したら跳ねたまま。1人のn=1観測ではありますが、「使う・使わない」が期せずしてON/OFFされたことで、単なる前後比較よりは因果に迫れるデータになりました。

正直な留保も添えます。7月前半の14日間は日曜2回を含めて一日も休んでおらず、複数案件の山場が重なった時期でもあります。「型」の改善も7月に止まったわけではありません。だから「2.0倍のすべてがモデルの寄与」とまでは言いません。それでも、6月の先行2日が7月水準を先取りしていた事実は、主因がモデルであることを強く示唆していると考えています。8月以降のデータで、この水準が定常かどうかを再検証するつもりです。

なお正確を期すと、7月2日以降も一度だけ、Fable 5の週次利用上限に当たってOpus 4.8へ一時フォールバックした日があります(7/9)。主戦の座は変わっていません。

Fable 5で何が変わったか

ベンチマークの点数の話は他所に譲るとして、実務で体感した変化は3つです。

1. 再指示の回数が減った。 旧世代では「指示→出てきたものを直させる→また直させる」の往復が前提でした。Fable 5は一発目の精度が上がったというより、曖昧さの残る指示から正しい側を選ぶようになりました。往復が減ると、私が同時に見られる並列作業の本数が増えます。生産性2倍の機序は、賢さ2倍ではなく並列度2倍です。

2. 専門領域の会話が成立する。 私の本業は金融系で、認証基盤や取引システムのような、業界の文脈を知らないと会話にならない領域があります。去年のモデルには毎回前提を補足していました。Fable 5とは、この領域でも補足なしで設計の議論ができています。ただし後述するとおり、これは「間違えなくなった」という意味ではありません。

3. 1セッションで完走する。 設計→実装→テスト→ビルド→検証→ドキュメント整合まで、途中で崩れずに走り切ることが増えました。7/9の56人日は、この「完走型」のセッションを並列で回した日です。

1月から積んできた「型」の話

モデルだけでは3.7倍(=1.84×2.0)にはなりません。半年で効いた順に挙げます。

1. 全作業のログ化とメモリ運用。 AIは毎セッション記憶を失います。だから、判断基準・過去の失敗・案件の文脈を全部ファイルに書き、次のセッションが読む構造にしました。特に効くのが「事故メモリ」で、AIがやらかした失敗(未コミットの変更を消した、勝手に外部投稿しかけた、監査で自信満々に誤検出した……)を、その場で再発防止ルールとして焼き込みます。件数は現在136本。事故率の推移は計測していませんが、百件を超えた頃から体感でははっきり減りました。

2. 艦隊レビュー。 大きな成果物は、複数のAIエージェント(私はSonnetを使います)に別々の観点でレビューさせ、さらに敵対的な検証役に反証を試みさせ、最後に上位モデルが裁定する多段構成にしています。自社アプリの品質監査では、1回の監査でSonnet 149体・約1,240万トークンを36分で回しました。1体のAIは平気で間違えますが、独立した多数のAIと裁定の層を挟むと、体感では人間のチームレビューに近い網羅性が出ます。

3. アンカー配布。 艦隊に仕事を出すとき、「確定済みの判断」(やらないと決めたこと、既知の制約、除外リスト)を先に文書で配ります。これをサボると、AIは既に決着した論点を蒸し返し、もっともらしい誤指摘を量産します。一度これで誤報告をやらかしてから、義務化しました。

4. 残タスクの一元管理。 TODOはリポジトリ直下の1ファイルだけを正本とし、「相手の反応待ちは書かない」「別フェーズの話は書かない」など、書かないルールを厳しくしました。AIとの並列作業では、タスクリストの腐敗が想像以上に速く進みます。

ちなみにこの記事の公開前レビューも同じ型で回しています。Sonnet 4体（ファクトチェック/コンプライアンス/統計的反証/懐疑的読者）に敵対的レビューをさせたところ、初稿から「Opusに戻っていません(→7/9のフォールバックと矛盾)」「6月平均にFable先行2日が混入(→用量反応の節に書き直し)」など複数の誤りが検出され、この最終稿に反映されています。

そして、入力は全部声

1日36人日分の作業をAIに指揮するとは、具体的には1日に数万文字分の指示と裁定を出すということです。これをキーボードで打つのは、物理的に無理でした。

私はこの半年の指示のほぼすべてを音声入力で出しています。設計の議論も、レビューの裁定も、この記事の元になった口述も、です。使っているのは自作の音声入力アプリkoedeskですが、音声入力が2倍の要因だという話ではありません。量をこなすための必須の入力手段だった、という話です。その上で、個人的な見立てとして確信に近いものがあります。AIと本気で働くようになった人から順番に、入力は声に移行する。プロンプトは会話体で長い。話すのは打つより速い。それだけの話です。

人間に残った仕事

最後に、一番聞かれそうな話を。「それ、あなた要らなくない?」

半年やった実感は逆です。実行がAIに移った分、私の仕事は裁定に濃縮されました。数えてみると、多い日は1日40回以上、何かを決めています。この算式は資料が間違っている、この提案はやらない、この表現は顧客に出せない——Fable 5になっても、AIは専門家の顔をして、専門家にしか気づけない間違いをたまに書きます。それを見抜いて止めることと、そもそも何をやるべきかを決めること。この2つだけは、まだ売り渡せていません。

正直に言えば、楽にはなっていません。低負荷な時間が消えて、判断だけが隙間なく続くので、疲れ方はむしろ濃くなりました。それでも、1月の自分には戻れません。生産性が2倍になる体験は、一度知ると後戻りできない類のものです。

この働き方の中身——艦隊レビューの組み方、事故メモリの運用、声で仕事を回す実際——は、これから順番に記事にしていきます。半年分のログには、まだ書けることが山ほど眠っているので。

なお、この記事自体も同じ作り方です。私が口述し、Claude Fable 5が起草し、Sonnet艦隊とFable 5と私がそれぞれファクトチェックして、私が直しました。

近藤政貴 — Guide Inc. Vietnam CEO