Claude Codeは、2025年10月からほぼ毎日使っています。会社では会社のライセンスで業務に、私用では自分で契約した**Max 5xプラン（月$100）**で使っています。

この記事は、その1年弱の本音です。良かったことも、勝手に進んで困ったことも、危ないと感じたことも、全部書きます。公式サイトの宣伝文句ではなく、実際に使った人間の感想として読んでください。

結論：3行で

  • 元は取れていると自信を持って言えます。Proに戻したら一瞬でトークン不足になり、Maxに戻しました
  • 一番の強みは、毎回指示しなくてもレビューまで自分でやること。一番の弱みは、方向を間違えても止まらずに進むこと
  • 勧めるのは**「やりたいことはあるのに手が回らない人」。最初にやるべきは、コードを書かせることではなくスキルとガードレールの設定**です

使い方の前提

項目 私の場合
使い始め 2025年10月
頻度 毎日
プラン 業務は会社ライセンス、私用はMax 5x（月$100）

用途は業務のコードだけではありません。私用ではブログの執筆、個人開発（アプリとインフラ）、動画制作など、まんべんなく使っています。

Proに戻して、すぐMaxに戻した

一度、月$20のProプランに落としたことがあります。結果は一瞬でトークン不足でした。毎日使う前提だと、Proの上限は私の使い方には足りず、Maxに戻しました。

プランごとの上限のしくみと日本円の目安は、Claude Codeの料金プラン比較に分けて書いています。この記事では「毎日使う人はMaxになる」という結論だけ覚えておいてください。

良かったこと

毎回指示しなくても、レビューまで自分でやる

一番驚いたのはここです。記事の執筆を頼むと、レビューについてその場で何も指示していなくても、勝手にレビュー工程を挟んで戻してきます。

しかも自分で自分を見直すセルフレビューではありません。執筆を担当したエージェントとは役割を分けた別のサブエージェントにレビューを委託するので、別の視点でチェックが入ります。これが品質の下支えになっています。

実例を出します。このブログの料金プラン記事を書かせたとき、レビュー担当のサブエージェントは出典と照合して15件の指摘を返してきました。その1つがこれです。

L121「1日$2,000の利用上限があり」 — 出典の原文は “There is a daily redemption limit of $2000.” で、これは Add funds（前払い入金）の1日あたり上限です。「利用（消費）の上限」ではありません。

執筆側が「入金の上限」を「利用の上限」と読み違えていたのを、レビュー側が原文に当たって直しました。このレビュー工程がなければ、間違ったまま公開されていたはずです。

記事を書ける本数が変わった

導入前は、記事1本に時間がかかって月に1〜2本が限界でした。今は週5本でも書ける状態になっています。

ただし、実際に週5本出しているわけではありません。AIで量産した記事はGoogleのスパムポリシーに引っかかるおそれがあるので、ペースは意図的に落としています。「書けるようになった」のと「出すべき」は別です。

もう1つ地味に効いているのが、記事ネタの壁打ちです。「このネタは書けるか」「素材が足りないのはどこか」を相談すると、ヒアリング項目まで作ってくれます。

不満・限界

良くも悪くも、勝手に考えて進む

強みの裏返しです。指示していないことまで自分で考えて進めてくれるのは楽ですが、方向性が間違っていても止まらずに進んでしまうことがあります。だから、こちらが適宜「そっちじゃない」と方針転換の指示を出す必要があります。

実例があります。このブログの立ち上げで、Claude Codeは「記事詳細ページの修正PR」の上に「記事のPR」を積み上げる形で2本のPRを作りました。

私が両方をマージしたところ、記事は修正PRのブランチ側にマージされていて、本番には出ていませんでした。GitHubの仕様上、先にマージした側のブランチが残っていると、後のPRのベースが付け替わらないためです。

Claude Code自身も後から「積み上げPRにした判断ミス」と認めて、取り込み用のPRと再発防止ルールを出してきました。直るのは早いのですが、マージして初めて気づく類の間違いは、こちらが確認しない限り防げません。

体験していないことを書く

もう1つは、文章を書かせるときの癖です。自然な文章で、体験していないことを体験したかのように書いてしまいます。

姉妹ブログでは、公開前のレビューで38件の修正が入り、そのうち**16件が「体験していないことを書いた」**でした。詳しくはAIの下書きは、どこを間違えるのかにまとめています。

このブログでは対策として、「体験を創作しない」をプロジェクトのルールに明記し、実体験記事はヒアリングシートに私が回答してから書かせる運用にしています。

危ないと感じたこと：クレデンシャル

一番注意してほしいのが、クレデンシャル（APIキーやパスワード）の扱いです。

Claude Codeが間違ったことをするという話ではありません。作業の途中で「クレデンシャル情報はどこにありますか？」と聞かれることがあり、そこでユーザーが値をそのまま貼ってしまうことがあり得ます。特にエンジニアではない人が使う場合、チャット欄に秘密情報を貼ることの危うさに気づきにくいと思います。

対策はシンプルで、聞かれても値は貼らないことです。環境変数やシークレット管理の「置き場所」だけを伝えて、値そのものは会話に出さないのが安全です。

公式のセキュリティドキュメントにも、提案されたコマンドや変更を承認前にレビューするのはユーザーの責任だと明記されています。

Claude Code only has the permissions you grant it. You’re responsible for reviewing proposed code and commands for safety before approval.

（Claude Codeはあなたが許可した権限しか持ちません。提案されたコードやコマンドを承認前に安全性の面で確認するのは、あなたの責任です）

「任せられる」と「見なくていい」は違う、ということです。

月$100の元は取れているか

取れています。自信を持って言えます。

根拠は単純で、月1〜2本しか書けなかった記事が、週5本書ける状態になったからです。Max 5xは税込でおよそ月17,600円ですが（計算の根拠）、この差だけで十分に見合っています。

逆に言うと、Proの$20で足りる使い方なら、それで十分元が取れます。私は毎日使うのでMaxが必要でしたが、まずProで自分の使用量を測るのが正しい順番です。

どんな人に勧めるか

**「やりたいことがあるのに、なかなか手が回らない人」**です。

作りたいアプリや書きたい記事があっても、本業や生活の合間だと着手すらできない。そういう人にとって、Claude Codeは「手が回らない部分」を肩代わりしてくれます。私のブログの執筆本数が変わったのは、まさにこれです。

これから始める人が最初にやること

コードを書かせることではなく、基礎的な設定です。具体的にはスキルの設定とガードレールの設定の2つ。

  • ガードレール: プロジェクトのルールファイル（CLAUDE.md）に「やってはいけないこと」を書く。このブログでは「体験を創作しない」「出典を示せない主張は書かない」「料金は公式ページで確認して確認日を書く」を書いています
  • スキル: 繰り返す作業の手順をスキルとして登録する。私の環境では、記事執筆の手順（構成案→執筆→サブエージェントのレビュー→PR作成）を姉妹ブログ用に作ったスキルにまとめ、このブログでも流用しています

上で書いた「勝手に進む」「体験を創作する」という弱点は、どちらもこの設定でかなり抑えられます。逆にここを飛ばして使い始めると、姉妹ブログで38件直したのと同じ経験をすることになります。

まとめ

  • 2025年10月から毎日使用。私用はMax 5x（月$100）。Proでは一瞬でトークン不足になった
  • 強みは毎回指示しなくてもレビューまで別エージェントで自走すること。料金記事で15件の指摘が返ってきた
  • 弱みは方向を間違えても止まらないことと、体験を創作すること。どちらも人のレビューとルール設定で抑える
  • クレデンシャルは聞かれても貼らない。承認前に確認するのはユーザーの責任
  • 元は取れている。ただしまずProで使用量を測ってからMaxが正しい順番

**「やりたいことがあるのに手が回らない」**なら、月$20のProから試す価値はあります。ただし最初にやるのはコードではなく、ガードレールの設定です。