Claude Codeで開発はどこまで変わるのか──押さえておきたい12の主要機能

Claude Codeを使い始めた人の多くが、最初にやることは同じです。ターミナルでclaudeと打って、「このバグ直して」と頼む。直る。すごい。……で、しばらくするとこう思うはずです。「便利だけど、もっとうまく使えるんじゃないか?」と。

実際、Claude Codeは「AIにコードを書かせるツール」としてだけ見ると、その能力の半分も使えていません。セッションをまたいで設定を記憶させる仕組み、ファイル変更を安全に巻き戻す機能、外部ツールとの連携プロトコル、タスクを分割して並列処理するサブエージェント──こうした機能を組み合わせることで、Claude Codeは「賢いオートコンプリート」から「プロジェクトを一緒に回す開発パートナー」へと変わります。

とはいえ、公式ドキュメントを全部読んで体系的に理解するのは骨が折れます。そこで本記事では、Claude Codeの主要機能を12個に整理して、それぞれ「何ができるのか」「どんな場面で使うのか」を実務目線でまとめました。すでに使い込んでいる人にも、これから触ってみようという人にも、全体像をつかむ地図として役立つはずです。

※ 本記事はこちらの動画の内容をベースに構成しています。

1. CLAUDE.md ── セッションをまたぐ「記憶」ファイル

Claude Codeは新しいセッションを開始するたびに、プロジェクトの構成やコーディングルールをリセットしてしまいます。この問題を解決するのがCLAUDE.mdです。

プロジェクトのルートディレクトリに置くMarkdownファイルで、コーディングの好みやプロジェクト構成などを自由に記述できます。Claudeはセッション開始時に必ずこのファイルを読み込み、「記憶」として活用します。たとえば「常にユニットテストを書くこと」と書いておけば、毎回指示しなくても自動的に従ってくれます。

書式に決まりはなく、短く・人間が読みやすい形で書くのがポイントです。/initコマンドを実行すると、現在のプロジェクトに合わせたCLAUDE.mdを自動生成してくれます。

2. Permissions(権限設定) ── スピードと安全性のバランスを調整する

コーディングエージェントはファイルを編集したりコマンドを実行したりできるため、強力である反面リスクも伴います。デフォルトでは、Claudeはファイル編集やBashコマンド実行のたびに確認を求めてきます。

Permissionsを使えば、この挙動を細かくカスタマイズできます。テスト実行やコードのコミットなど「安全なアクション」は事前に承認済みにしておき、ファイルの削除など「危険なアクション」はブロックする、といった設定が可能です。セッション中に/permissionsと入力するとメニューが開き、許可するツールの追加・削除をインタラクティブに操作できます。

最初は保守的な設定からはじめ、ワークフローへの信頼が高まるにつれて少しずつ開放していくのがおすすめです。

3. Plan Mode(計画モード) ── 動かす前に考えさせる

複雑なタスクをいきなり実行させると、Claudeが間違ったファイルを編集したりトークンを無駄に消費したりすることがあります。Plan Modeは計画と実行を明確に分離するための機能です。

Shift + Tabでプランモードと通常モードを切り替えられます。プランモードではClaudeはファイルを読み、質問し、ステップバイステップの実行計画を提案しますが、ファイルの変更は一切できません(読み取り専用ツールのみ使用可能)。計画を確認・承認してから通常モードに切り替えることで、安心して実行を委ねられます。

4. Checkpoints(チェックポイント) ── いつでも安全に巻き戻せる

複数ファイルをリファクタリングした後に「アプローチが間違っていた」と気づいても、すべてを手動で元に戻すのは非常に手間がかかります。Checkpointsはこの悩みを解消します。

Claudeは編集のたびに自動でファイルのスナップショットを保存しており、セッション中に/restoreと入力するとタイムスタンプと説明つきのチェックポイント一覧が表示されます。復元したい時点を選ぶだけで、その状態にぴったり戻れます。

大胆な実験やリスクの高いアイデアも、動いているコードを失う心配なく気軽に試せるようになります。

5. Skills(スキル) ── 繰り返しの指示をファイルに切り出す

毎回同じ長い指示をプロンプトに入力するのは手間がかかります。Skillsは、Claudeがオンデマンドで読み込める「事前定義の指示セット」です。

各スキルはskill.mdというMarkdownファイルで、名前・説明・具体的な指示内容を記述します。セッション開始時に利用可能なスキルの一覧をClaudeに渡しておくと、必要なタイミングで適切なスキルを自動的に呼び出してくれます。

一度スキルを作っておけば、チーム全員が長いプロンプトを覚えることなく同じワークフローを再現できます。繰り返し作業を、共有・再利用可能な自動化へと昇華させる機能です。

6. Hooks(フック) ── 特定のタイミングで処理を自動実行する

「コードを変更するたびに必ずフォーマットをかけたい」など、毎回必ず実行したい処理があるケースに対応するのがHooksです。

Claudeのワークフローループには特定のポイントがあり、そこにスクリプトを差し込んで自動実行させることができます。ツール実行の前後など、タイミングは自由に指定可能です。フォーマット、セキュリティチェック、ログ記録など、必ず一定の動作が保証されるべき処理に特に向いています。

7. MCP(Model Context Protocol) ── 外部ツールとシームレスに連携する

Claudeはファイルの読み込みやBashコマンドの実行はできますが、FigmaやSlackなどの外部ツールとはどう連携するのでしょうか。これを解決するのがMCP(Model Context Protocol)です。

MCPは、誰でもツールをビルドしてエージェントに公開できるオープンプロトコルです。MCPサーバーを追加するだけで、そのサーバーが提供するすべてのツールにClaudeがアクセスできるようになります。すでに公開されている数千のMCPサーバーを即座に利用できる点も魅力です。

8. Plugins(プラグイン) ── 環境設定をまるごとチームに配布する

カスタムスキルやフック、MCPサーバーなどを組み合わせた理想的な環境を構築しても、チームメイトに同じ環境を共有するのは手間がかかります。Pluginsはこの問題を解決します。

プラグインはスキル・フック・エージェント・MCPサーバー・メタデータを一つにまとめた「バンドル」です。作成したプラグインをマーケットプレイスやGitリポジトリに公開すれば、チームメイトは1コマンドでインストールできます。環境構築の手順書を書く必要も、口頭で説明する手間もなくなります。

9. Context(コンテキスト管理) ── 200kトークンの中身を可視化する

Claude Codeは約200,000トークンの固定コンテキストウィンドウの中で動作します。会話が長くなるほどこのウィンドウが埋まっていき、やがて古い内容が失われてしまいます。

/contextコマンドを実行すると、現在何がコンテキストを消費しているか——CLAUDE.md、スキル、MCPツールの説明、会話履歴などの内訳を詳細に確認できます。「なんだかClaudeの応答が変になった」と感じたとき、まず確認すべきはこのコマンドです。

10. Compact(自動圧縮) ── 会話を賢く要約して容量を確保する

コンテキストの中身を把握できたら、次に重要なのが容量管理です。コンテキストが上限に近づくと、Claudeは重要な意思決定の内容を保持しながら会話を自動で圧縮(compact)します。

大切な内容が失われそうな場合は、自動圧縮が走る前に手動で/compactを実行しておくと安心です。「今までの議論で大事なところは残して、それ以外は圧縮して」というようなカスタム指示を添えることもできます。長いセッションで作業するときほど、この機能のありがたみを実感するはずです。

11. Slash Commands(スラッシュコマンド) ── よく使う操作をショートカット化する

毎回同じ操作をプロンプトに入力するのは効率が悪いです。Slash Commandsは、Claude Codeにおけるキーボードショートカットのような存在です。

コストの確認、コンテキスト管理、セッションのクリアなど、頻繁に使うワークフローを/に続けてコマンド名を入力するだけで素早く呼び出せます。ここまで紹介した/init/permissions/restore/context/compactもすべてスラッシュコマンドです。日々の操作のテンポを大きく改善してくれる機能です。

12. Sub Agents(サブエージェント) ── 複雑なタスクを分割して並列処理する

複雑なタスクをすべて1つのセッションで処理しようとすると、コンテキストが混雑しやすくなります。Sub Agentsは、特定の仕事専用に立ち上げる別のClaudeセッションです。

Claudeは複雑なタスクを小さなピースに分解し、それぞれのサブエージェントに委譲します。サブエージェントは独立して作業し、短いサマリーをメインセッションに返します。/agentsから「Create Agent」を選んで、名前と専門領域に特化したプロンプトを設定するだけで使えます。

メインの会話をクリーンに保ちながらコンテキストウィンドウを効率的に活用できるため、大規模な調査・並列作業・専門的なタスクに特に有効です。

まとめ

機能 概要
1. CLAUDE.md セッションをまたぐ記憶・ルールファイル
2. Permissions ツール実行の事前承認・ブロック設定
3. Plan Mode 実行前に計画だけを立てるモード(Shift + Tab)
4. Checkpoints 自動スナップショットで任意の時点に巻き戻し
5. Skills 繰り返しの指示をMDファイルで再利用可能にする
6. Hooks ワークフロー内の特定タイミングでスクリプトを自動実行
7. MCP 外部ツールと連携するためのオープンプロトコル
8. Plugins スキル・フック・MCPをバンドルしてチームに配布
9. Context 200kトークンウィンドウの中身を可視化
10. Compact 会話を賢く圧縮して容量を確保
11. Slash Commands 頻繁な操作をスラッシュ入力でショートカット化
12. Sub Agents 専門タスク専用の独立セッションで並列処理

これらの機能を組み合わせることで、Claude Codeは単なるコード補完ツールを超えた、本格的な開発パートナーとして機能します。まずはターミナルを開いてclaudeと入力し、実際に触れてみてください。


文:植田(ハバス合同会社 研究開発部)

PerplexityやChatGPTに自分の記事を引用させる方法──東大研究発の”構造だけで差がつく”GEO戦略

「ChatGPTに引用されるコンテンツって、結局どう書けばいいの?」——AI検索が当たり前になった今、コンテンツ制作者なら誰もが一度は考えたはずの問いです。

この問いに対して、東京大学・筑波大学・広島大学の研究チームが2026年3月に興味深い論文を発表しました。タイトルは 「Structural Feature Engineering for Generative Engine Optimization: How Content Structure Shapes Citation Behavior」。日本語で言えば、「コンテンツの構造が、AIの引用行動をどう左右するか」を体系的に調べた研究です。

結論を先に言ってしまうと——文章の中身を変えなくても、構造を整えるだけで引用率が平均17.3%向上したという結果が出ています。今回はこの論文「GEO-SFE」を、実務目線で読み解いてみます。

そもそもGEOとは?

GEO(Generative Engine Optimization)は、ChatGPT、Perplexity、Google AI Overviews、ClaudeなどのAI検索エンジンに「引用されやすいコンテンツ」をつくる施策の総称です。SEOが「検索結果でクリックされる」ことを目指したのに対し、GEOは「AIの回答の中で言及される」ことがゴール。

従来のGEO研究は、「統計データを盛り込む」「権威ある引用を入れる」「断定的な言い回しにする」といった文章の意味的な改善に集中してきました。一方で、見出しの付け方、段落の長さ、太字の使い方といった構造的な要素がどれだけ引用率に影響するかは、ほとんど解明されていなかったのです。

提案された手法「GEO-SFE」

論文では、コンテンツの構造を3つの階層に分解して定量化し、それぞれを最適化するフレームワーク「GEO-SFE」を提案しています。

1. マクロ構造(文書全体の設計)

見出しの階層、セクション同士のつながり、内部リンクの密度など、文書全体のアーキテクチャを指します。論文の分析によると——

  • 見出しの階層は3〜5段がベスト(深すぎるとAIの注意が分散、浅すぎると整理されていないと判断される)
  • 内部リンクの密度は0.15〜0.20が理想
  • セクション間の意味的な連続性が高いほど引用されやすい

2. メソ構造(段落・セクションレベル)

段落の長さやリスト・表などの構造化要素の使い方です。ここがけっこう実務的に重要。

  • 段落の長さは150〜300語が最適(日本語で言えば概ね300〜600文字程度)
  • 300語を超えると、段落の中盤で注意力が31%低下するという別研究の知見と一致
  • 150語未満だと情報が分断され、引用確率が23%下がる
  • リスト・表・コードブロックなど構造化要素は全体の25〜35%を占めるのが理想
  • 構造化された情報は、プレーンな散文と比べてAIの抽出精度が43%高い

3. ミクロ構造(文・語レベル)

太字・イタリックなどの強調や、キーワードの配置位置です。

  • 強調マーカーはコンテンツ全体の5〜10%に絞る(多すぎると逆効果)
  • 強調の効果は 太字 > イタリック > 下線 の順
  • キーワードは文頭またはセクション境界に配置すると注意を集めやすい(文中の標準位置と比べて2倍の注意を引く)

AI検索エンジンによって「好み」が違う

面白いのは、論文がAI検索エンジンを3つのアーキテクチャに分類し、それぞれに最適な戦略が異なると指摘している点です。

アーキテクチャ 代表例 重視される構造
Search-then-Synthesize型 Google SGE、Bing Chat メタ構造の明確さ、冒頭の情報密度
Iterative Refinement型 Perplexity、Phind 相互参照の豊富さ、階層の幅
Integrated Search-Generation型 ChatGPT、Claude チャンクの独立性、フォーマットの多様性

つまり、ChatGPTやClaudeを意識するなら「各セクションが単独で意味を成すように書く」「リストや表を積極的に使う」が効きやすく、Perplexityを狙うなら「内部リンクや関連情報の網目を充実させる」のが効くということになります。

実験結果——どれくらい効果があったか

研究チームは、GEO-bench(GEO評価用の標準データセット)から200記事を抽出し、6つの主要AI検索エンジン上で、最適化前後の引用率を比較しました。総テスト件数は2,400件です。

主な結果

  • 全体の引用率が +17.3%(統計的に有意、p < 0.001)
  • Search-then-Synthesize型. :+19.2%
  • Iterative Refinement型. :+14.0%
  • Integrated Search-Generation型:+19.7%
  • 主観的な品質評価(G-Eval)でも平均 +18.5% の改善
  • 特に「影響力」(+32.0%)と「クリック確率」(+31.4%)の向上が顕著

3階層のうち、どこが効いたのか?

各階層を取り除いた実験(アブレーション分析)では、引用率向上への寄与は——

  • マクロ構造:44.9%
  • メソ構造 :39.7%
  • ミクロ構造:15.4%

つまり、太字やキーワード位置といったミクロな調整より、文書全体の見出し設計と段落構成のほうが圧倒的に効くということ。これは納得感があります。

明日から使える実践的なチェックリスト

論文の知見をそのまま記事制作に落とし込むと、こんな感じになります。

  • ✅ 見出し階層は3〜5段に収める(H2、H3、H4くらいまで)
  • ✅ 1段落は300〜600文字程度を目安に
  • ✅ リスト・表・引用ボックスを意識的に挟む(全体の1/4〜1/3が理想)
  • ✅ 太字は使いすぎず、5〜10%以内に抑える
  • ✅ キーワードは文頭やセクション冒頭に置く
  • ✅ 各セクションが単独でも意味が通るよう、文脈を補足する
  • ✅ 関連記事への内部リンクを適切な密度で配置する

論文を「使える」形にした──Claude Codeスキル「geo-sfe」を公開しました

……とはいえ、チェックリストを毎回手動で確認しながら記事を書くのは、正直しんどい。そこでハバスでは、このGEO-SFE論文の手法をClaude Codeのカスタムスキルとして実装し、GitHubで公開しました。


Claude Navi

こちらで紹介しています:https://claudenavi.com/app/geo-sfe

何ができるのか?

2つのスラッシュコマンドを追加するだけのシンプルなスキルです。

コマンド できること
/geo-analyze コンテンツの構造を3階層で分析し、改善提案をレポート(geo-report.md)として出力
/geo-optimize GEO-SFEフレームワークに基づいて、コンテンツの構造を自動最適化(意味は保ったまま)

インストール

Claude Codeが既に入っている環境なら、コマンド一発で導入できます。

git clone https://github.com/havaslabo/geo-sfe.git
cd geo-sfe
./install.sh

使い方

執筆中の記事ファイルがあるディレクトリでClaude Codeを起動し、スラッシュコマンドを叩くだけ。

# カレントディレクトリ以下の全記事を分析
/geo-analyze
 
# 特定のファイルだけ最適化
/geo-optimize article.md
 
# 狙うAI検索エンジンを指定して最適化
/geo-optimize article.md sts   # Google SGE / Bing Chat 向け
/geo-optimize article.md ir    # Perplexity / Phind 向け
/geo-optimize article.md isg   # ChatGPT / Claude 向け

論文に出てきた3つのアーキテクチャ(Search-then-Synthesize / Iterative Refinement / Integrated Search-Generation)に対応した最適化モードを用意しているので、どのAI検索エンジンでの引用を狙うかに応じて使い分けられます。

注意点として、/geo-optimizeは元ファイルを上書き保存します。実行前にGitでコミットしておくのを推奨します(というか、しないと痛い目を見ます)。

中身はシンプル

スキルの実体は、論文の手法を構造化したMarkdownファイル(Claude Codeのカスタムコマンド定義)です。Claude自身が論文の3階層ルールを読み込んで、文書を解析・最適化してくれる仕組み。Pythonの依存関係もAPIキーも不要で、Claude Codeさえあれば動きます。

実装を読めば「論文をどうプロンプトに落とし込んだか」も見られるので、GEOに興味がある方・Claude Codeのスキル開発に興味がある方にも参考になるかと思います。

まとめ——GEOは「中身」と「構造」の両輪へ

これまでGEOの議論は「何を書くか」に偏りがちでしたが、今回の論文は「どう構造化して見せるか」も同じくらい重要だと示しました。とくに、文書全体の設計(マクロ構造)が引用率の45%近くを左右するという発見は、コンテンツ制作の優先順位を見直すきっかけになります。

AI検索の比重がますます高まる2026年、コンテンツ制作者にとって「AIに読まれやすい構造」を意識することは、もはやオプションではなく前提になりつつあります。難しいことではありません。読者にとって読みやすい構造は、たいていAIにとっても読みやすいのです。

論文の原文はarXivで公開されていますので、より詳しく知りたい方はぜひ。


文:植田(ハバス合同会社 研究開発部)


参考文献:Junwei Yu, Yang MuFeng, Yepeng Ding, Hiroyuki Sato. “Structural Feature Engineering for Generative Engine Optimization: How Content Structure Shapes Citation Behavior.” arXiv:2603.29979, March 2026.

AIに設計をレビューさせる——検証ループで品質を上げる方法

AIが設計をレビューし、別のAIが修正する——「設計検証ループ」という新しいアプローチ

ソフトウェア開発において、設計の品質がその後の実装全体に影響を与えることはよく知られています。しかし「設計レビュー」は属人的になりがちで、時間もかかる工程です。私たちはこの課題に対して、複数のAIモデルを組み合わせた「設計検証ループ」という仕組みを構築しました。 

本記事で紹介する内容は 2026 年 2 月時点のものです。 当時はまだ Sonnet 4.5 の時代でした。

着想のきっかけ——検証ループはコードだけのものではない

Claude Codeの開発者であるBoris Cherny氏は、検証ループの重要性について自身のXで言及しており、フィードバックループがあれば最終結果の品質は2〜3倍向上すると述べています。1)

この考え方はコードの実装フェーズに向けたものでしたが、私は疑問を持ちました。「設計段階で検証ループを回したらどうなるか」。当時、要件定義や設計は人の手で行うべきという認識が主流でした。それでも試してみると、設計の品質が大きく変わることが確認できました。

なぜレビューと修正を別のAIに担当させるのか

最初に浮かぶ疑問は「なぜ1つのAIで完結させないのか」という点です。

理由は単純で、作成者が自分の成果物をレビューすると、評価が甘くなるからです。これは人間のレビューでも起きる現象ですが、AIも同様です。Anthropicの公式ドキュメントには「A fresh context improves code review since Claude won’t be biased toward code it just wrote.」2)(筆者訳:新鮮なコンテキストはコードレビューの質を高める。Claudeは自分が書いたコードへのバイアスを持たない状態でレビューできるからだ)と記されています。自分が生成した設計を自分でレビューさせると、見落としが増え、問題を指摘しにくくなる傾向があります。

そのため、このループではClaudeがレビューを担当し、GPT-5が修正を担当するという役割分担を採用しています。異なるモデルが異なる視点で関わることで、指摘の客観性が上がります。

ループの流れ

1. 要件・仕様の入力(プランモード)

まず要件と仕様を整理し、設計案を作成します。この段階ではコードを書かず、設計の方針を固めることに集中します。

2. Claudeがレビュー

設計案に対してClaudeがレビューを実施し、問題点を指摘します。評価は以下10の観点に基づき、0〜100のスコアで数値化されます。

# 観点
1 完全性 — 必要な情報がすべて含まれているか
2 一貫性 — 設計の各部分が矛盾していないか
3 実装可能性 — 現実的に実装できるか
4 拡張性 — 将来の変更に対応できるか
5 保守性 — メンテナンスしやすいか
6 パフォーマンス — 性能上の問題はないか
7 セキュリティ — リスクはないか
8 テスタビリティ — テストしやすい設計か
9 ベストプラクティス — 業界標準に沿っているか
10 技術選択 — 技術スタックは適切か

なお、このスコアは客観的な計算式ではなく、モデルがプロンプトに従って主観的に判断した値です。同じ設計でもモデルによってスコアがブレる可能性があります。これがレビュアーモデルを途中で変えると整合性が崩れやすい理由でもあります。

3. GPT-5が修正

Claudeの指摘を受けてGPT-5が設計を修正します。修正は以下の優先順位で行われます。

  • P0(必須): 全件の指摘が修正済みであること
  • P1(改善): 1件ずつ、観点をローテーションしながら改善
    • 反復1: セキュリティ
    • 反復2: 設計原則(SOLID / 責務分離)
    • 反復3: テスト戦略
    • 反復4: パフォーマンス……

4. スコア判定

修正後の設計を再評価します。

– スコア < 85点 かつ 指摘あり → ループを継続

– スコア ≥ 85点 または 指摘ゼロ → 実装フェーズへ移行

運用して分かったこと

85点を超えると実装レベルのコードが出てくる

スコアが85点を超えた設計から生成されるコードは、実装にそのまま使えるクオリティになることが確認できました。85点という目標値は、過度な完璧主義を避けつつ実用的な品質を担保するバランスとして機能しています。

レビュアーはClaude以外も選択できる

レビュアーのモデルはGPTやGeminiに差し替えることも可能です。ただし、スコアはモデルの主観的判断に依存するため、レビュアーを途中で変えると基準が変わりスコアの連続性が失われます。1つのループは同じモデルで通すことを推奨します。

まとめ

 「AIに作らせてAIにレビューさせる」という構成は一見シンプルに見えますが、同じAIに作成とレビューを兼任させないという設計が品質向上の鍵です。

Boris Cherny氏が述べるように、検証ループの構築はシンプルです。「AIに結果を見るツールを与え、そのツールについて教える。これだけ」。設計フェーズにこの考え方を持ち込んだことで 、実装品質が大きく変わることが実感できました。

後書き

また、今回の取り組みでは、OSS 的な“差分前提の学び方”を意識し、 モデルやツールの更新に合わせて、必要な部分だけを検証・更新するプロセスを取り入れています。 これは「毎回ゼロから学び直す」のではなく、 変化した部分だけを追い、差分だけを反映するというアプローチです。

本記事で紹介した内容は 2026 年 2 月時点のもので、 当時はまだ Sonnet 4.5 の時代でした。 その後の Claude Code をはじめとした LLM モデルの進化の速さを見ると、 差分駆動の学習方法こそが、変化に追随するための現実的なアプローチだと改めて感じます。

今後も、急速に変化し続ける技術に対して、 差分を捉えながら理解を更新し続ける姿勢で、変化に向き合い続けたいと思います

 

参考文献

1) Boris Cherny.X投稿.2025-01.https://x.com/bcherny/status/2007179861115511237,(参照 2026-01-21).

2) Anthropic.”Best Practices for Claude Code”.Anthropic Claude Code Docs.https://code.claude.com/docs/en/best-practices,(参照 2026-04-13).