Claude Codeを触り始めると、いつの間にかホームディレクトリやプロジェクトに 見慣れないファイルが増えていくのに気づきますよね

CLAUDE.md settings.json AGENT.md SKILL.md .mcp.json ……名前は見たことがあるけど、「どれを触ると何が変わるのか」が把握しきれていない、という方は多いんじゃないでしょうか

この記事では、Claude Codeを使うときに登場する 主要な設定ファイル(.md含む)を一覧化して、保存場所と役割をまとめます

「Claudeが勝手に作るけど、いざ触る場面で慌てたくない」「自分用に微調整したい」という人が、早見表的に開いて参照できるような構成にしました

拡張機構の全体像についてはClaude Codeの拡張機構入門(基礎編)、用語の整理はClaudeを始める前に知っておきたい用語集で扱っているので、ベースから入りたい方はそちらと合わせてどうぞ

まず知っておきたい全体像と継承ルール

細かいファイル一覧に入る前に、大枠の地図を頭に入れておきましょう

Claude Codeの設定は、大きく 2つの軸で整理できます

1. 場所の軸:ユーザー全体(~/.claude/)とプロジェクト個別(<project>/.claude/)
2. 役割の軸:指示(Markdown)と挙動制御(JSON)と拡張機構(Markdown+YAML)

※ ~/ はホームディレクトリの省略表記で、Windowsなら C:\Users\<ユーザー名>\、Mac/Linuxなら /Users/<ユーザー名>/ や /home/<ユーザー名>/ に読み替えてください

つまり同じ settings.json でも 「どこに置くか」で適用範囲が変わるし、同じ「Markdownの指示書」でも CLAUDE.md と SKILL.md と AGENT.md で読まれ方が違うわけです

設定ファイルの階層イメージ

典型的な配置を図にするとこんな感じになります

~/.claude/                          ← ユーザー全体(全プロジェクト共通)
├── CLAUDE.md                       全体共通の指示
├── settings.json                   全体共通の挙動制御
├── skills/<name>/SKILL.md          個人スキル
└── projects/<project>/memory/
    ├── MEMORY.md                   メモリー目次
    └── <topic>.md                  個別メモリー

<project>/                          ← プロジェクト個別
├── CLAUDE.md                       プロジェクト指示
├── CLAUDE.local.md                 ローカル専用指示(gitignore)
├── README.md                       一般ドキュメント(間接参照)
├── .env                            認証情報(gitignore)
├── .gitignore                      バージョン管理除外
├── .mcp.json                       MCPサーバー登録
└── .claude/
    ├── settings.json               プロジェクト共有設定
    ├── settings.local.json         ローカル専用設定(gitignore)
    ├── rules/<name>.md             特定パス限定指示
    ├── skills/<name>/SKILL.md      プロジェクト固有スキル
    ├── agents/<name>/AGENT.md      サブエージェント定義
    └── hooks/<script>              Hookスクリプト本体

このツリーが頭に入っていると、「あ、これはユーザー全体に効くやつだな」「これはプロジェクト固有か」がすぐ判断できるようになります

継承ルールの基本

同じ役割のファイルが複数の階層に置かれているとき、どれが優先されるかは役割ごとにルールがあります

ここでとくに重要なのが、CLAUDE.md は上書きではなく『連結』されるという点です

ユーザー全体の CLAUDE.md と、プロジェクトの CLAUDE.md と、サブディレクトリの CLAUDE.md があったら、全部まとめて1つの巨大な指示書としてClaudeに渡されるイメージです

なので「上書きされるはずだから雑に書いておけばいい」みたいな運用は通用しません、書いたものは全部効いてくるので注意しましょう

プロジェクト指示・コンテキスト系

ここからカテゴリ別に 主要な設定ファイルを見ていきます、まずは Claudeに「こういう方針で動いて」と伝える系のファイルです

このカテゴリは触る頻度が一番高いので、優先的に押さえておきたいところになります

CLAUDE.md(グローバル)|全プロジェクト共通の指示書

• 場所:~/.claude/CLAUDE.md
• 形式:Markdown
• 触る頻度:高め(自分の好みが固まってきたら追記)

個人として「どのプロジェクトでも同じように動いてほしい」内容を書く場所です

たとえば「日本語で返答してね」「コミットメッセージは英語のconventional commitsで」「pythonは仮想環境を有効化してから実行して」みたいな、自分のスタンダードを宣言するイメージになります

注意点として、ここに書いた内容はすべてのプロジェクトのコンテキストに毎回入るので、肥大化するとトークン消費が増えます、本当に共通の事項だけにとどめるのが運用のコツです

CLAUDE.md(プロジェクト)|プロジェクトごとの指示書

• 場所:<project>/CLAUDE.md
• 形式:Markdown
• 触る頻度:高め(プロジェクトの方針を整理するたびに追記)

プロジェクトごとに違う情報を書く場所で、設定ファイルの中で一番触る機会が多いのがここになります

使っているフレームワーク・ディレクトリ構成のクセ・命名規則・テストの走らせ方・このプロジェクト特有の禁止事項など、「新人が入ってきたら最初に渡したい資料」に近いものを書くイメージです

複数階層に置けるのもポイントで、ルートに置いた CLAUDE.md に加えて、サブディレクトリ(たとえば backend/ や frontend/)にも個別の CLAUDE.md を置けば、その配下にいるときだけ追加で読まれます

大規模プロジェクトで役割ごとに指示を分割したい場合に効いてくる仕組みです

CLAUDE.local.md|gitignore対象のローカル指示

• 場所:<project>/CLAUDE.local.md
• 形式:Markdown
• 触る頻度:中(自分用メモを置きたいとき)

名前のとおり自分のローカル環境専用の指示書です、Gitで共有したくない個人メモを書く場所になります

たとえば「自分の検証用APIキーはここに置いてある」「個人的にこのプロジェクトで試している実験設定はこれ」みたいな、チームに共有する必要がない情報を書きます

このファイルは継承順で最後に追記される=実質一番優先される仕組みになっているので、プロジェクトのデフォルト動作を自分だけ一時的に変えたいときにも便利です

ただし忘れずに .gitignore に CLAUDE.local.md を入れておかないと、うっかりコミットしてしまうことがあるので注意しましょう

rules/ ディレクトリ|特定パスに限定した指示

• 場所:<project>/.claude/rules/<name>.md
• 形式:Markdown + YAML frontmatter
• 触る頻度:低〜中(細かい運用が固まってきたら作る)

CLAUDE.md が「全体方針」なら、こちらは 『この種類のファイルを触るときだけのルール』を書く場所です

frontmatterで paths を指定して、たとえば **/*.test.ts にマッチするファイルを開いているときだけ「テストはVitestで」「モックは最小限に」みたいなルールを発動させられます

---
paths:
  - "**/*.test.ts"
  - "**/*.spec.ts"
---

このプロジェクトのテストは Vitest を使う

- describe / it ではなく test() の単独形式
- モックは vi.mock() で最小限に
- スナップショットテストは原則使わない

CLAUDE.md がどんどん肥大化してきたら、役割ごとに rules/ へ分割していくのが整理のコツになります

README.md|間接的に参照される一般ドキュメント

• 場所:<project>/README.md
• 形式:Markdown
• 触る頻度:低(リポジトリの説明用)

これはClaude専用ファイルではないですが、Claudeはプロジェクトを開いたとき初回探索で README.md を読みに行く傾向があるので、ここにプロジェクト概要・セットアップ手順・ディレクトリ構成などを書いておくと初手の理解が早くなります

「Claude専用に書く」のではなく 『普通のドキュメントを充実させると、結果としてClaudeも賢く動く』という考え方が分かりやすいかもしれません

全体設定・挙動制御系

続いて、Claude Codeの 挙動そのものを制御する設定ファイル群です、ここはMarkdownではなくJSONで書く世界になります

settings.json の3階層

settings.json は3つの階層に置けて、それぞれ役割が違います

この3つは マージされる仕組みで、優先順位は Managed > CLI flag > Local > Project > User の順になっています(Managedは企業デプロイ向けで、個人運用ではあまり意識しなくてOK)

つまり同じキーがあれば Local が Project を、Project が User を上書きする形になります

settings.json の主要フィールド

知っておくと役立つフィールドをピックアップして整理しました

とくに permissions は セキュリティの要になる部分で、ここで deny リストを整えるかどうかで安心感がガラッと変わります

具体的な書き方はClaude Code Desktop初心者向けセキュリティの記事で詳しく扱っているので、合わせて読むと理解が深まります

最小サンプル|settings.json の中身

とりあえず書き始めるなら、こんな感じの構造から入るのが分かりやすいです

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force *)"
    ],
    "ask": [
      "Edit",
      "Write"
    ]
  },
  "env": {
    "PYTHONIOENCODING": "utf-8"
  },
  "autoMemoryEnabled": true,
  "model": "claude-sonnet"
}

このファイルは 慣れるまでコピペで始めるのが現実的、Claude公式ドキュメントや既存サンプルを土台にして、自分のプロジェクトに合わせて少しずつ削ったり足したりするのが良い感触です

hooks フィールド|自動処理の宣言場所

settings.json 内の hooks フィールドは、イベント駆動の自動処理を宣言する場所です

「ツールを使う前にこのスクリプトを走らせて」「セッション開始時にこれを実行して」みたいな指定をJSONで書きます、スクリプト本体は別ファイル(.claude/hooks/<name>)に置くのが一般的です

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/check-dangerous.sh"
          }
        ]
      }
    ]
  }
}

主なイベントは SessionStart UserPromptSubmit PreToolUse PostToolUse Stop あたりで、機械的に確実に走らせたい処理がある場合に使います

初心者向けには優先度低めで、Claude Codeに慣れて「定型処理を自動化したい」と感じたタイミングで触り始めれば十分だと思います

拡張機構系|サブエージェントとスキル

Claude Codeを 自分用に拡張する仕組みで使われるファイル群です、ここからは中級者向けの色が濃くなってきます

AGENT.md|サブエージェントの定義ファイル

• 場所:<project>/.claude/agents/<name>/AGENT.md
• 形式:Markdown + YAML frontmatter
• 触る頻度:中(サブエージェントを使う運用なら必須)

サブエージェント(Subagent)を1個1個「こういう仕事をする専門係」として定義するファイルです

frontmatterで name description tools model などを指定し、本文にはそのエージェントが守るべき行動指針を自然言語で書きます

たとえば「コードレビュー専用エージェント」「リサーチ専用エージェント」みたいに役割を分けて、メインのClaudeセッションから委譲できる仕組みです

frontmatterの主要フィールドは次のような構成です

サブエージェントを使うと メインのコンテキストを汚さずに重いタスクを処理できるので、大規模プロジェクトで効いてきます

SKILL.md|スキル定義ファイル

• 場所(個人):~/.claude/skills/<name>/SKILL.md
• 場所(プロジェクト):<project>/.claude/skills/<name>/SKILL.md
• 形式:Markdown + YAML frontmatter
• 触る頻度:中(よく使う作業をテンプレ化したくなったら作る)

スキル(Skill)は「よく使う指示パターンをまとめてClaudeに覚えさせる」仕組みで、その本体ファイルが SKILL.md になります

frontmatterで name description when_to_use allow-tools user-invocable などを指定して、本文にスキルが実行すべき手順や注意事項を書きます

呼び出し方法は3パターンあって、以下のように整理できます

個人スキルはホームディレクトリ、プロジェクト固有スキルはプロジェクト内に置けるので、『どこに置くか』で誰と共有するかを分けられます

commands/ ディレクトリ|レガシー扱いの旧コマンド機構

• 場所:<project>/.claude/commands/<name>.md
• 状態:Skills(SKILL.md)に統合され、新規利用は非推奨

以前はカスタムスラッシュコマンドを commands/<name>.md として置く方式がありましたが、2026年5月現在は Skills(SKILL.md)に統合されています

過去の記事やGitHubのサンプルで commands/ 配下の .md を見かけることがありますが、新規に作るならSKILL.md側で書くのがおすすめです

SKILL.mdの user-invocable: true を指定すれば、これまで通り /コマンド名 でユーザー側から呼び出せる挙動が再現できます

連携・運用系|外部接続とメモリー

続いて、Claude Codeの外側とつなげるための設定ファイルや、長期的な情報を覚えておくためのファイル群です

.mcp.json|MCPサーバーの登録

• 場所(プロジェクト):<project>/.mcp.json
• 場所(ユーザー):~/.claude.json の mcpServers フィールド
• 形式:JSON
• 触る頻度:中(MCPサーバーを追加するたびに編集)

MCP(Model Context Protocol)サーバーの接続情報を書く場所です

「WordPressに投稿するMCPサーバー」「データベース操作のMCPサーバー」みたいな外部連携を増やすたびに、ここに登録していくイメージになります

{
  "mcpServers": {
    "wordpress": {
      "command": "python",
      "args": ["./wp_mcp_server.py"],
      "env": {
        "WP_BASE_URL": "https://example.com"
      }
    }
  }
}

ポイントは user scope と project scope の2階層に置けること、共通で使うMCPはユーザー側、プロジェクト固有のMCPはプロジェクト側、と振り分けると整理しやすいです

.env|認証情報・APIキー

• 場所:<project>/.env
• 形式:KEY=VALUE のテキスト
• 触る頻度:中(認証情報を追加するたびに編集)

Claude専用というわけではないものの、Claude Codeで外部APIや独自MCPサーバーを使うとき、認証情報の置き場として頻出します

パスワード・APIキー・アクセストークンなど 原則Gitには上げない情報をここに集約しておきましょう

WP_BASE_URL=https://example.com
WP_USERNAME=admin
WP_APP_PASSWORD=xxxx xxxx xxxx xxxx

.gitignore に .env を入れておくのは運用上の鉄則になります、忘れるとGitHubに認証情報が漏れる事故につながります

MEMORY.md / 個別 memory|プロジェクト固有の長期記憶

• 場所:~/.claude/projects/<project>/memory/MEMORY.md と <topic>.md
• 形式:Markdown
• 触る頻度:中(自動で書き換わる、手動編集は最小限)

Claude Codeの自動メモリー機能が、会話の中で得た情報をプロジェクト固有の知識として書き出していくファイル群です

MEMORY.md が目次で、トピック別の個別ファイル(user_profile.md project_context.md など)が実体として並ぶ構造になっています

基本的にClaudeが自分で書き換える領域なので、頻繁に手で編集する場所ではないですが、「ここに書かれた情報を見直したい」とか「明らかに古い情報が残っている」みたいなときに開いて整えるのは有効です

settings.json の autoMemoryEnabled でメモリー機能の有効/無効を切り替えられるので、邪魔ならOFFにする選択肢もあります

.gitignore|バージョン管理から外したいファイル

• 場所:<project>/.gitignore
• 形式:テキスト(パターン1行ずつ)
• 触る頻度:中(新しい設定ファイルを増やすたびに点検)

Claude専用ではなくGit本来のファイルですけど、Claude Code関連のファイルを増やすたびに点検すべき場所として外せません

Claude Code関連で .gitignore に入れておきたい代表的なパターンはこんな感じです

# Claude Code ローカル専用ファイル
.env
CLAUDE.local.md
.claude/settings.local.json

# 必要に応じて
.claude/cache/
*.log

逆にチームで共有したい設定(.claude/settings.json .claude/agents/ .claude/skills/ .mcp.json など)は .gitignoreに入れないのが原則になります、ここをきれいに分けておけば運用がぐっと安定します

プラグイン系|こういうのもあるよ

最後に、ちょっと発展形としてプラグイン系のファイルも紹介しておきます、こちらは 中級〜上級者向けの領域なので、初心者の方は「こういうのもあるんだな」程度で大丈夫です

plugin.json|プラグインのマニフェスト

• 場所:<plugin-root>/.claude-plugin/plugin.json
• 形式:JSON
• 触る頻度:低(プラグインを自作するなら必須)

Claude Codeのプラグインを1つのパッケージとして配布するときに、そのマニフェスト情報を書くファイルです

プラグイン名・バージョン・作者・含まれているスキルやエージェントの一覧などを記述します

プラグイン同梱のskills / agents / hooks

• 場所:<plugin-root>/skills/ agents/ hooks/ 配下
• 形式:Markdown / JSON
• 触る頻度:低(プラグイン開発者向け)

プラグインに同梱される拡張機能の本体ファイル群です、プラグインをインストールすると、ここのファイルがあたかも自分が書いたかのようにClaude Codeから読み込まれる仕組みになっています

Hooksをまとめた hooks/hooks.json もこの中に置かれることがあって、ユーザー側の settings.json を汚さずに自動処理を配布できる利点があります

まとめ|どこから手を付けるか

ここまでで主要な設定ファイルを一通り見てきましたが、『結局どこから触ればいいの?』という疑問が残るかもしれません

個人的にはClaude Codeを始めた人の流れとして、以下の順番で触っていくのが 無理なく押さえやすいと思っています

1. CLAUDE.md(プロジェクト):何はなくともプロジェクトの方針をここに書く、最も触る頻度が高い
2. settings.json + .gitignore + .env:権限と認証情報を整える、セキュリティの土台になる
3. CLAUDE.md(グローバル):全プロジェクトで共通の好みが固まってきたら追加
4. SKILL.md:同じ指示を何度も書いていることに気づいたらテンプレ化、Markdown1ファイルで始められる
5. .mcp.json:外部サービスと連携したくなったら登録、公式コネクタから始めるのが現実的
6. AGENT.md:重いタスクが増えてきて、メインコンテキストを汚したくなくなったら導入
7. rules/ + hooks:プロジェクト固有の運用が固まってきた段階で整理、運用熟練者向け

大切なのは『全部を一気に触ろうとしない』こと、Claude Codeはハーネス層が広いので、いきなり全カテゴリを整えようとすると確実に挫折します

困りごとが出てきたら、その時点で関連ファイルを1つだけ触る、ぐらいのペースが結果的に長続きすると思います

早見表|主要ファイル一覧

最後にもう一度、この記事で扱った主要ファイルを1枚の早見表として整理しておきます、ブックマークしてリファレンス的に使ってもらえると嬉しいです

各ファイルの細かい使い方はClaude Codeの拡張機構入門(基礎編)やClaudeの使い方を初心者向けに解説した記事でも触れているので、深掘りしたい部分があれば合わせて読んでみてください

Claude Codeはまだまだ進化中で、設定ファイルの種類や役割も少しずつ変わっていく可能性があります、この早見表も折を見て追記していく予定なので、また覗きに来てもらえると嬉しいです

Claudeを使い始めると「ハルシネーション」「コンテキストウィンドウ」「MCP」みたいな用語が当たり前のように記事に出てきて、なんとなく分かるけど聞かれると説明しにくい、ということが結構ありませんか

この記事は、Claudeを始めた方向けに AI記事を読むときによく出てくる用語38個をやさしくまとめた辞書代わりのページです

頭から読んでもいいですし、知らない用語に出会ったときにブックマークから戻ってくる使い方でもOKです

Claude自体の基本的な使い方はClaudeの使い方を初心者向けに解説した記事でまとめているので、まだ触ったことがない方はそちらから読むと入りやすいです

セクションは4つに分けています

1. AIの世界の基本ワード(8語)
2. AIとのやりとりで出てくる言葉(12語)
3. Claudeの製品・機能名(12語)
4. Claude独自の考え方・モード(6語)

1. AIの世界の基本ワード

まずは大枠を押さえるための基本8語です、Claudeに限らずAI関連の話を読むなら必ず出てくる用語ばかり

AI / 人工知能

人間がやっていた知的な作業を、コンピュータにやらせる技術全般を指す広い言葉です

音声認識・自動翻訳・画像認識・自動運転・チャットボットなど、すべてAIに含まれます

普段ニュースで聞く「AI」は、後述する「生成AI」を指していることが多いです

生成AI(Generative AI)

何かを生み出すタイプのAIで、文章・画像・音声・コードなど人間が作っていたものをAI自身が作ってくれます

Claude / ChatGPT / Gemini / Midjourney / Sora などはすべて生成AIです、2022年ごろから一気に話題になったジャンル

LLM(大規模言語モデル)

大量の文章を学習して言葉を扱えるようになったAIの中身です、Large Language Modelの略

ChatGPTやClaudeの裏で動いているのがこのLLMで、生成AIの中でも「文章系」を担当する存在です

「Claude」というのはサービスや製品の名前で、その裏で動く頭脳がLLM、というイメージを持つと整理しやすいです

機械学習・ディープラーニング

AIに「学習」をさせる仕組みの総称が機械学習、その中でも特に賢く学習させる方法がディープラーニング(深層学習)です

ざっくり言えば AIの賢さの源泉になっている部分、ここがあるおかげで人間が一つひとつルールを書かなくてもAIが自分でパターンを見つけて答えられるようになりました

ニューラルネットワーク

人間の脳の神経細胞のつながり方を模した計算の仕組みです、ディープラーニングの中身の構造

「層」が深く重なっているからディープ(深層)ラーニング、と呼ばれます

細かい仕組みを知らなくても使うぶんには問題なし、「AIは脳の真似をした計算をしてる」とざっくり押さえれば十分

マルチモーダル

文章だけでなく、画像・音声・動画など複数の形式を扱えるAIのことです

ClaudeもChatGPTも、PDFや画像をアップロードして「これ要約して」と頼める時代になりましたが、これがマルチモーダルの恩恵です

逆に文章しか扱えない初期のAIは「シングルモーダル」と呼ばれます(あまり使わない言葉ですが)

AIエージェント

「質問に答える」だけでなく 自分で考えて手順を踏みながら作業を進めてくれるAIのことです

たとえば「来週の出張の準備をして」と頼んだら、ホテルを調べ、新幹線を予約し、リマインダーを設定し、必要な資料をまとめる、までを一連で進めてくれるイメージ

2026年現在、最も注目されているAIの方向性で、ClaudeのCowork機能もこの流れの中にあります

バイブコーディング

「こういう感じのアプリを作って」とノリ(vibe)でAIに頼んで、AIにコードを書いてもらうスタイルのことです

非IT職でも、プログラミング知識ゼロでアプリやツールが作れる時代になった象徴的な言葉

実際にバイブコーディングでWindowsアプリを作ってみた話はこちらの記事でまとめているので、雰囲気が気になる方は覗いてみてください

2. AIとのやりとりで出てくる言葉

Claudeなど生成AIを使う上で、ほぼ毎回出てくる12語です、ここを押さえると記事を読むスピードが一気に上がります

プロンプト

AIに対する指示文・質問文のことです、要するに「あなたが入力欄に打ち込む文章」

「○○について教えて」「この文章を要約して」みたいな依頼すべてがプロンプトです

プロンプトエンジニアリング

AIから望む答えを引き出すために、プロンプトを工夫する技術です

「あなたはプロのコピーライターです」みたいに役割を与えたり、「ステップごとに考えて」と指示したり、出力例を見せたり、いろんなテクニックがあります

同じAIでも頼み方ひとつで結果が大きく変わるので、知っておくと得な技術です

システムプロンプト

会話全体に対する役割設定や前提条件をAIに伝える、特別なプロンプトです

たとえば「あなたは丁寧語で答える秘書です」「コードを書くときは必ずコメントを入れて」みたいに、会話のたびに毎回伝えなくていい指示をまとめておく場所

ClaudeのProjects機能やChatGPTの「カスタム指示」がこれに相当します

ハルシネーション

AIが事実と違うことを、もっともらしく言ってしまう現象のことです、いわゆる「AIの嘘」

固有名詞・日付・数字・出典など、具体的な情報ほどハルシネーションが起きやすいので、AIの回答を鵜呑みにせず裏取りする習慣が大事です

「ハルシネーション=幻覚」という英単語が語源、AIが見えないものを見えているように答えてしまうイメージから来ています

トークン

AIが文章を扱うときの単位で、ざっくり「単語の切れ端」みたいなもの

日本語だと 1文字あたり1〜2トークンくらいが目安で、文字数とほぼ比例して考えればOK

料金やレスポンスの長さの上限はトークン数で決まることが多いので、「だいたい何文字くらいで何トークン」を意識すると使い勝手が良くなります

コンテキストウィンドウ

AIが一度に覚えていられる会話の長さのことです

このウィンドウからあふれた古いやり取りはAIが忘れてしまうので、長い会話が続くと「さっき言ったこと忘れてる?」みたいな現象が起きます

Claudeは 20万トークン(約数十万字)と業界最大級のコンテキストウィンドウを持っていて、長い書類を読ませる用途に強い特徴があります

ファインチューニング

既存のAIに追加データを学ばせて、特定の用途に特化させることです

「医療用語に強いAIにする」「自社の社内文書スタイルで答えるAIにする」など、土台のAIを自分用にカスタマイズする使い方

プロンプトで指示を工夫するのとは別次元で、AI自体の中身を変える話なので、開発者向けの上級者向けテーマです

RAG(検索拡張生成)

Retrieval-Augmented Generationの略で、AIが回答するときに、外部のデータベースや文書を検索して参考にする仕組みです

ファインチューニングがAI自体を作り変えるのに対し、RAGは AIに「カンペ」を渡して回答させるイメージ

社内マニュアルを参照しながら答える社内向けチャットボットなど、業務利用でいま一番伸びている方式です

アライメント

AIの振る舞いを、人間の意図や価値観に沿わせる取り組みのことです

「人を傷つけることを答えない」「危険な情報を出さない」「指示にちゃんと従う」みたいな、AIを「役立つけど安全」にするための調整全般を指します

ClaudeをつくるAnthropicは このアライメント研究を重視している会社として知られていて、後述のConstitutional AIなどはその代表例です

思考の連鎖(Chain of Thought)

AIに「順を追って考えて」と指示することで、答えの精度を上げるテクニックです、略してCoTとも呼ばれます

計算問題や論理的な質問で、いきなり答えだけ出させるよりも「ステップごとに考えて」と頼んだ方が正答率が上がる、という発見からきています

Claudeなど最近のAIは内部で自動的に思考の連鎖をする能力が上がっていて、後述の「拡張思考」もこの考え方の発展形です

推論(Inference)

AIが答えを生成する処理そのものを指します

「学習(training)」が事前にAIを賢くする工程なのに対して、「推論(inference)」は実際に質問に答える本番動作のこと

クラウドサービスの料金は「推論にかかる計算コスト」が大半なので、「推論コスト」という言葉も覚えておくとAI関連の経済ニュースが理解しやすくなります

API

プログラムからAIを直接呼び出すための窓口のことです、Application Programming Interfaceの略

普段の使い方(Webやアプリのチャット画面で会話する)とは別に、自分で作ったプログラムからAIを呼べる仕組みで、自動化や独自アプリの開発に使われます

「OpenAI API」「Claude API」のように、各社が提供しています、ニュースで「APIで連携」と聞いたら「プログラム同士をつないでる」と思えばOK

3. Claudeの製品・機能名

ここからはClaude特有の用語に入ります、製品ラインナップと主要機能の12語

Anthropic(アンソロピック)

Claudeを開発しているAI企業の名前です

2021年にOpenAI(ChatGPTを作った会社)の元メンバーが設立した会社で、特に「AIの安全性」に重きを置いた研究で知られています

GoogleやAmazonと提携していて、企業向けにも幅広く採用されています

Opus / Sonnet / Haiku(3つのモデル)

Claudeには 用途別に3つのモデルがあって、賢さと速さのバランスで使い分けます

俳句の形式(短い・中くらい・長い)から名前が取られていて、SonnetとHaikuは日本人にも馴染みのある単語ですね

claude.ai(Web版)

ブラウザでClaudeを使うときのアドレスです、claude.aiにアクセスして会話するスタイル

あとで出てくる「Claude Code Desktop」が専用アプリ版なのに対して、こちらはブラウザだけで完結する手軽な使い方

初心者はまずWeb版から触ってみるのが手っ取り早いです

料金プラン(Free / Pro / Max)

Claudeには 3段階の個人向け料金プランがあります

料金は2026年5月時点のもの、為替やプラン改定で変動する可能性ありなので最新情報は公式サイトでどうぞ

Artifacts(アーティファクト)

Claudeが作ったコード・文書・図表を、サイドパネルにプレビュー表示してくれる機能です

「HTMLとCSSでランディングページを作って」と頼むと、その場でレンダリングされて見れるとか、コードや長文がチャットの流れに埋もれず独立したエディタのように扱える、というメリットがあります

2024年あたりから本格化した機能で、Claudeの強みのひとつ

Projects(プロジェクト)

テーマや用途ごとに会話とファイルを一つのまとまりで管理できる機能です

「ブログ執筆用」「業務マニュアル用」「副業の経理用」のようにプロジェクトを分けておくと、それぞれの中ではClaudeが前提条件を覚えた状態で会話できるので、毎回同じ前置きを書かなくて済みます

プロジェクトごとに システムプロンプト(前述)を登録できるのもポイント、ProプランやMaxプランで使えます

Claude Code Desktop

Claudeのデスクトップアプリ版で、ローカルファイルを直接読み書きしながら作業できる開発者向けモードです

普通のWeb版Claudeに対して、Claude Code Desktopは 自分のPCのファイルやフォルダを直接いじれるのが大きな違い

プログラミングだけでなく、ファイル整理やドキュメント作成にも使えるパワフルなツールですが、それだけにセキュリティ対策も大事になります

コネクタ(Connectors)

ClaudeをGoogle DriveやSlackなど外部サービスと公式に連携させる仕組みです

2026年から無料プランでも一部使えるようになり、「Google DriveのドキュメントをClaudeから直接読む」みたいな使い方が普通にできるようになりました

後述の「MCP」が自作の連携を作る仕組みなのに対し、コネクタは Anthropic公式が用意した既製の連携、という違いがあります

ファイルアップロード

Claudeのチャット入力欄から PDF・Word・Excel・画像などのファイルをそのまま渡せる機能です

「このPDFを3行で要約」「このExcelの傾向を読み取って」みたいに頼めば、長文資料も一発で整理してくれます

無料プランでも使えるので、Claudeを試すならまずファイル要約を体験するのがおすすめ

MCP(Model Context Protocol)

AIに外部サービスを操作させるための共通言語(規格)で、Anthropicが提唱しています

MCPに対応した「MCPサーバー」を作っておけば、ClaudeがWordPressに記事を投稿したり、データベースを参照したり、自由に外部とやりとりできるようになります

2026年現在 AIエージェント業界の標準規格になりつつある注目技術で、これからますます重要になる用語です

Skills(スキル)

Claudeに特定の作業手順を「スキル」として覚えさせる機能です

「PowerPointを作るときのフォーマット」「議事録のまとめ方」みたいな繰り返しの作業手順を、スキルとして登録しておけば、毎回手順を伝えなくても同じ品質でこなしてくれます

2026年に登場した比較的新しい機能で、これから活用法が広がる予定

Cowork(コワーク)

ClaudeがあなたのPC画面を実際に操作してくれるエージェント機能です

「このフォルダの資料から提案書を作って」と目的を伝えると、ファイルを自分で開いて、読んで、まとめる、までを自律的にこなしてくれるイメージ

Desktop版限定の機能で、AIエージェントの考え方を実現した代表的な実装

4. Claude独自の考え方・モード

最後に、Claude記事を読んでいると出てくる独特の考え方やモード名を6個

拡張思考(Extended Thinking)

Claudeに 「じっくり考えてから答えてね」と頼める特殊なモードです

通常は即座に答えるところ、拡張思考をONにすると、内部で何段階かに分けて推論してから答えを出してくれます、正答率や論理性が大きく上がる代わりに少し時間がかかります

難しい数学問題・複雑なコーディング・長文の論理チェックなどで使うと効果的

Plan Mode(プランモード)

Claude Code Desktopで使える 「いきなり作業せず、まず手順だけ提示してね」というモードです

大きな変更や、初めての作業のときに使うと「想定外の動きをされる事故」を防げます

Shift+Tabキーでモード切替できます

自動モード

Claude Code Desktopで 「安全な操作は自動で進めてOK、危険なものはちゃんと止めてね」というバランスモードです

後述の「許可をバイパス」と混同されがちですが、こちらは denyルールを守る安全な方です

慣れてきて毎回の確認が面倒になってきたら、これを選ぶのがおすすめ

許可をバイパス

Claude Code Desktopの 「すべての権限チェックを無視して動作させるモード」です

名前のとおりすべての安全ガードを外すため、設定したdenyルールも無効化されます、原則に有効化しないのが鉄則

「自動モード」と名前が似ているので混同注意、こちらは 危険な方です

Constitutional AI(憲法AI)

Anthropicが独自に開発した、AIに「憲法」のような原則を覚えさせて安全に振る舞わせる学習方法です

「人間に害を与えない」「正直であれ」みたいな原則をAIに守らせる仕組みで、Claudeが 「安全性が高い」と評価される根拠のひとつ

ChatGPTのRLHF(人間のフィードバックで学習)と並ぶ、代表的なアライメント技術

ツール使用(Tool use)

AIが自分で外部のツールを呼び出して使う仕組みです、Function callingとも呼ばれます

「電卓を使って計算する」「Web検索する」「カレンダーを開く」など、AI単体ではできない作業を、必要に応じて外部ツールに任せる仕組みで、AIエージェントの中核的な技術

MCPやコネクタ・Coworkなどの機能はすべて、このツール使用の発展形と言えます

まとめ|まずは使いながら覚えるのが一番

用語38個、お疲れさまでした

全部を最初から覚える必要はなくて、Claudeを触りながら「あ、これさっき記事で出てきた言葉だ」と紐づけていくのが一番自然な覚え方です

個人的に 最初に押さえると一気に世界が広がる5つをピックアップするとしたら、こんな感じ

• LLM 〜 AIの中身、これだけで会話の解像度が上がる
• プロンプト 〜 自分が打つ文章の正式名称、聞き方を変えると結果が変わる
• ハルシネーション 〜 AIの嘘、必ず裏取りする習慣の根拠
• コンテキストウィンドウ 〜 「忘れられた」現象の正体
• AIエージェント / MCP 〜 今後数年のAI話題の中心、ここから外れた話題はあまり出てこない

用語が分かるようになると、AI関連のニュースや記事を読むストレスがぐっと減るので、ぜひこのページをブックマークしておいて、知らない言葉に出会ったときに戻ってきてください

Claudeの始め方はこちらの記事に、バイブコーディングでアプリを作った話はこちらにまとめてあるので、合わせてどうぞ

「VBAでJSONを読み込みたいんだけど、標準機能だとどうにもならない…」と手が止まっていませんか？

結論から言うと、ExcelVBAでJSONを扱うなら「VBA-JSON」という定番ライブラリを入れるのが一番ラクです

やることはシンプルで、JsonConverter.bas というファイルを1つ取り込んで、参照設定を1つ入れるだけ、あとは ParseJson でJSONを読み込んで、ConvertToJson でJSONを書き出せます

この記事では、VBA-JSONの導入から実際の使い方(パース・生成・配列やネストへのアクセス・ループ処理)まで、初心者の方にも分かるように順を追って解説していきます、つまずきポイントとFAQ、AIにコードを書いてもらうコツもまとめているので、必要なところだけ拾い読みでも大丈夫です

VBAでJSONを扱うなら VBA-JSON が定番

まず大前提として、VBAには標準でJSONを扱う機能がありません

Excelには CSV を読む機能はあっても、JSONをそのまま「項目ごとに取り出す」みたいなことは素のVBAだとできないんですよね

そこで使うのが、オープンソースのライブラリ「VBA-JSON」です

GitHubの VBA-tools/VBA-JSON で公開されていて、JSON界隈ではかなり知られた定番です、最新は v2.3.1 で、WindowsのExcelでもMacのExcelでも動きます

使う関数は基本的にこの2つだけ覚えればOKです

• ParseJson … JSON文字列を、VBAで扱えるデータ(Dictionary / Collection)に変換する(=読み込む)
• ConvertToJson … VBAのデータを、JSON文字列に変換する(=書き出す)

「読み込む」と「書き出す」の往復、これだけです、難しそうに見えて中身はシンプルなので安心してください

VBAでJSONを扱う場面はどんなとき？

そもそも「ExcelでJSONなんて使うの？」と思うかもしれませんが、最近のWeb APIはJSONで返ってくるのがほぼ標準なので、意外と日常業務の中で出番があります

たとえばこんなケースです

• 為替レートや天気予報のWeb APIを叩いてExcelに取り込む
• WebサービスからダウンロードしたデータをVBAで集計する
• 取引先のシステムとJSON形式でデータをやり取りする
• WordPressや社内システムのREST APIを操作する

VBA-JSONを使えるようになると、Excel完結の作業に外部データを取り込める幅が一気に広がります、普段の集計シートに「最新のデータを自動で引っ張ってくる」ような仕組みを足せるイメージですね

実際にWeb APIへリクエストを送ってJSONを受け取る流れは、eBay APIにVBAでリクエストを送る方法を解説した記事でも具体例を扱っているので、API連携をやってみたい方はあわせてどうぞ

そもそもJSONって何？という人向けの基礎

「JSONって言葉は聞くけど、よく分かってない」という方のために、ここで一度ざっくり整理しておきます、もう分かってる方は読み飛ばしてOKです

JSON(JavaScript Object Notation)は、テキストベースのデータ交換フォーマットです

Web APIからデータを取得するとき、他システムとのデータやり取りなど、いろんな場面で使われています、軽量で人間にも機械にも読みやすいのが特徴ですね

JSONの基本構造と記述ルール

細かいルールはいくつかありますが、まず押さえておきたいのはこのあたりです

• 項目名は「”」(ダブルクォーテーション)で囲む
• 文字列も「”」(ダブルクォーテーション)で囲む
• 数値は小数点を含めてそのまま表記(クォーテーション不要)
• 真偽値(Boolean)は「true」「false」のどちらか ※小文字、「”」は付けない
• Null値は「null」 ※小文字、「”」は付けない
• 「[ ]」で囲んだ配列の中も、上記と同じルール

形としては「"キー": 値」のセットが基本で、複数のデータを { } で囲んだものを「オブジェクト」、順序のあるデータの並びを [ ] で囲んだものを「配列」と呼びます

このあたりの言葉は、VBA-JSONを使うときに何度も出てくるので、なんとなく頭に入れておくと後がスムーズです

JSONのサンプルをExcelの表で考えてみる

JSONはCSVほど一目で分かる形式じゃないので、サンプルと一緒に見方を説明します、この記事ではずっとこのデータを例に進めていきます

たとえばこんなJSON形式のデータがあるとして

[{"name":"Javeo","birthdate":{"year":2000,"month":1,"day":1},"height":180,"weight":70,"favorite_foods":["Meat","Vegetables"],"glasses":true},{"name":"Javelin","birthdate":{"year":2002,"month":2,"day":2},"height":150,"weight":null,"favorite_foods":["Sweets"],"glasses":false}]

一行だと分かりづらいので、整形するとこうなります(VSCodeなどのエディタで簡単に整形できます)

[
  {
    "name": "Javeo",
    "birthdate": {
      "year": 2000,
      "month": 1,
      "day": 1
    },
    "height": 180,
    "weight": 70,
    "favorite_foods": [
      "Meat",
      "Vegetables"
    ],
    "glasses": true
  },
  {
    "name": "Javelin",
    "birthdate": {
      "year": 2002,
      "month": 2,
      "day": 2
    },
    "height": 150,
    "weight": null,
    "favorite_foods": [
      "Sweets"
    ],
    "glasses": false
  }
]

これをExcel的に表にすると、こんなイメージになります

つまりJSONをざっくり言うと、項目と値が対になっていて、「{ }」が階層を、「[ ]」が配列のデータ群を表していると思えばOKです

この「JaveoとJavelinの2人分のデータ」を、これからVBA-JSONで取り出していきます

VBA-JSONの導入手順(2026年版)

ここが一番大事なパートです、導入でつまずく人が多いので、順番にやっていきましょう

やることは大きく分けて2つ、「JsonConverter.basのインポート」と「参照設定」だけです

STEP

ライブラリのダウンロード

GitHubのVBA-tools/VBA-JSONリポジトリにアクセス

STEP

ファイルを探す

ページ内にある「JsonConverter.bas」をダウンロード

※何年も更新されていませんが、文字列を分解するだけのプログラムで特に改良点がないってだけなので気にせずどうぞ

STEP

VBAへのインポート

VBAで使えるようにするにはVBEの画面でインポートするだけ

プロジェクトエクスプローラー
右クリック→「ファイルのインポート」

もしくは「JsonConverter.bas」をプロジェクトエクスプローラーへドラッグ&ドロップでもOK

STEP

Microsoft Scripting Runtime に参照設定する

VBA-JSONを動かすには参照設定が要ります

VBA-JSONは内部で「Dictionary」という、キーと値をセットで扱うデータの入れ物を使っています、このDictionaryをそのまま書くスタイル(早期バインディングと言います)で動かすために、Microsoft Scripting Runtime への参照設定が必要になります

設定はVBEのメニューからで、手順はこうです

1. VBEのメニューで「ツール → 参照設定」を開く
2. 一覧から「Microsoft Scripting Runtime」を探す
3. チェックボックスにチェックを入れて「OK」を押す

これを忘れると、コードを実行したときに「ユーザー定義型は定義されていません」というエラーが出ます、後ろのFAQでも触れますが、この参照設定はかなりの確率でハマるので先に済ませておくのがおすすめです

Mac の Excel で使う場合

MacのExcelには Microsoft Scripting Runtime が無いので、参照設定の代わりに同じ作者の「VBA-Dictionary」というライブラリを一緒に入れます

VBA-tools/VBA-Dictionary から Dictionary.cls をダウンロードして、JsonConverter.bas と同じようにインポートすればOKです、WindowsとMacの両方で動かしたいときも、参照設定ではなくこのVBA-Dictionaryを使う形にしておくと安心ですね

ここまでできたら準備は完了です、いよいよ実際にJSONを扱っていきます

ParseJson でJSONを解析(パース)してみる

JSON形式のテキストを、VBAで扱えるデータ構造(DictionaryやCollection)に変換することを「解析(パース)」と言います

このパースが、ParseJson 関数を使えばたった一行で完了します

まずはWeb APIからJSONを取ってきてパースする、いちばんよくある形のサンプルです

' /// 事前準備 ///
' VBEの [ツール] > [参照設定] から下記にチェックを入れる
' ・Microsoft Scripting Runtime   (Dictionary用、VBA-JSONに必須)
' ・Microsoft XML, v6.0           (APIを叩く場合)
Sub GetJsonData()
    Dim http As Object
    Dim jsonText As String
    Dim parsedData As Object ' 解析後のデータ格納用

    ' Web APIからJSONデータを取得(例)
    Set http = CreateObject("MSXML2.XMLHTTP")
    http.Open "GET", "https://javeo.jp/wp-json/test/v1/data", False
    http.send
    jsonText = http.responseText

    ' ここがVBA-JSONの本体、JSONを解析
    Set parsedData = ParseJson(jsonText)

    ' 解析したデータをデバッグ出力
    Debug.Print "名前: " & parsedData(1)("name")
    Debug.Print "身長: " & parsedData(1)("height")

    Set http = Nothing
    Set parsedData = Nothing
End Sub

長く見えるかもしれませんが、VBA-JSONを使っている箇所は、結局このたった一行だけです

Set parsedData = ParseJson(jsonText)

この一行を通すことで、最初のサンプルにあった「長いただの文字列」が、parsedData(1)("name") といった具合に要素を指定してデータを取り出せる構造に変わります

APIを使わず、手元の文字列をそのままパースして試すこともできます、まずは動きを確かめたいときはこちらが手っ取り早いです

Sub ParseSample()
    Dim jsonText As String
    Dim parsedData As Object

    ' 動作確認用に文字列を直接用意
    jsonText = "[{""name"":""Javeo"",""height"":180}]"

    Set parsedData = ParseJson(jsonText)

    Debug.Print parsedData(1)("name") ' → Javeo
    Debug.Print parsedData(1)("height") ' → 180
End Sub

VBAの中で「”」を書くときは「””」と2つ重ねる必要があるので、そこだけ少し読みづらいですが、やっていることは「文字列をパースして取り出す」だけです

パースしたJSONから値を取り出す(配列・オブジェクト・ネスト)

ここがVBA-JSONを使ううえで一番つまずきやすく、そして一番大事なところです

ポイントは、パース後のデータが「Dictionary」と「Collection」の2種類に化けているという点です

• JSONの「{ }」(オブジェクト)→ Dictionary になる(キー名で取り出す)
• JSONの「[ ]」(配列)→ Collection になる(番号で取り出す)

この区別さえ分かれば、あとは指定の仕方が決まります、サンプルの「JaveoとJavelinのデータ」を例に、ひとつずつ見ていきましょう

配列(Collection)は番号で取り出す

サンプルのJSONは全体が「[ ]」で囲まれた配列なので、パース直後の parsedData はCollectionになっています

Collectionは「何番目」という番号(インデックス)で要素を取り出します、VBAのCollectionは1番から始まるのがポイントで、0番からじゃないので注意です

' 1人目(Javeo)のデータを取り出す
Set firstPerson = parsedData(1)

' 2人目(Javelin)のデータを取り出す
Set secondPerson = parsedData(2)

オブジェクト(Dictionary)はキー名で取り出す

取り出した1人分のデータ(parsedData(1))は「{ }」のオブジェクトなので、こちらはDictionaryです

Dictionaryは番号ではなく、キー名(項目名)を指定して値を取り出します

' 1人目の名前と身長
Debug.Print parsedData(1)("name")   ' → Javeo
Debug.Print parsedData(1)("height") ' → 180

' 真偽値もそのまま取れる
Debug.Print parsedData(1)("glasses") ' → True

parsedData(1)("name") は「配列の1番目(Collection)→ その中のnameキー(Dictionary)」という読み方になります、カッコが連続するのは、この2段階を一気に書いているからなんですね

ネスト(入れ子)は同じ要領でつなげる

サンプルの birthdate は、中にさらに year / month / day を持つ「入れ子のオブジェクト」です、こういうネストも、考え方は同じでカッコをつなげるだけです

' 1人目の生年月日(birthdateの中のyear)
Debug.Print parsedData(1)("birthdate")("year")  ' → 2000
Debug.Print parsedData(1)("birthdate")("month") ' → 1

' 配列の中の値(favorite_foodsの1個目)
Debug.Print parsedData(1)("favorite_foods")(1) ' → Meat

コツは、「{ }が来たらキー名」「[ ]が来たら番号」をJSONの形に合わせて交互に書いていくだけ、整形したJSONを見ながら指でたどると間違えにくいです

ループでまとめて処理する

実際の業務では「全員分をシートに書き出す」みたいに、繰り返し処理(ループ)で回すことがほとんどです

配列(Collection)は For Each でぐるっと回せます

Sub WriteToSheet()
    Dim parsedData As Object
    Dim person As Object
    Dim i As Long

    Set parsedData = ParseJson(jsonText) ' jsonTextは取得済みとする

    i = 1
    ' 配列の要素(1人分のデータ)を1件ずつ取り出す
    For Each person In parsedData
        Cells(i, 1).Value = person("name")
        Cells(i, 2).Value = person("height")
        Cells(i, 3).Value = person("birthdate")("year")
        i = i + 1
    Next person
End Sub

キー名が分からないオブジェクトを総当たりで見たいときは、.Keys でキー一覧を回す手もあります

Dim key As Variant
' 1人目のオブジェクトのキーと値を全部出す
For Each key In parsedData(1).Keys
    Debug.Print key & " = " & parsedData(1)(key)
Next key

ここまでで「読み込む(パース)」側はバッチリです、配列は番号・オブジェクトはキー名、これさえ押さえれば、たいていのJSONは取り出せます

ConvertToJson でVBAのデータをJSONに変換(生成)

今度は逆方向、つまりVBAのDictionaryやCollectionからJSON文字列を作る(生成する)パターンです、こちらは ConvertToJson 関数を使います

「VBAで作ったデータをAPIに送りたい」「JSON形式でファイルに保存したい」みたいなときに出番があります

Sub CreateJsonString()
    Dim postData As Object
    Dim skillsCollection As Collection
    Dim jsonString As String

    ' データを格納する親オブジェクトを準備
    Set postData = CreateObject("Scripting.Dictionary")

    ' 基本的なキーと値を追加
    postData("name") = "鈴木 一郎"
    postData("age") = 25

    ' 配列用のオブジェクトを「Collection」で準備
    Set skillsCollection = New Collection

    ' Collectionにデータを追加
    skillsCollection.Add "Word"
    skillsCollection.Add "PowerPoint"

    ' 親オブジェクトにCollectionを追加
    postData.Add "skills", skillsCollection

    ' DictionaryをJSON文字列に変換
    jsonString = ConvertToJson(postData)

    ' 結果をイミディエイトウィンドウに出力
    Debug.Print jsonString
    ' 想定される出力: {"name":"鈴木 一郎","age":25,"skills":["Word","PowerPoint"]}

    ' オブジェクトの解放
    Set postData = Nothing
    Set skillsCollection = Nothing
End Sub

ポイントは、JSONの「{ }」はDictionary、「[ ]」はCollectionで組み立てるという点です、パースのときと逆の対応関係になっているだけなので、慣れると自然に書けるようになります

この jsonString をWeb APIに送信(POSTなど)すれば、VBAで作ったデータをサーバーに送れます

改行付きで見やすく出力したいとき

デフォルトのままだと、生成されるJSONは改行なしの一行になります、人が読む用にきれいに整形したいときは、Whitespace オプションを付けます

' インデント2つ分で改行を入れて整形
jsonString = ConvertToJson(postData, Whitespace:=2)

ファイルに保存して中身を確認したいときなんかは、こちらのほうが見やすくておすすめです

VBA-JSONを使わずにJSONを扱う方法(JScript)

ここまでVBA-JSONをおすすめしてきましたが、「ライブラリを追加したくない」「配布先でインポートさせるのが面倒」というケースもありますよね

そういうときの代替案として、Windows標準のJScriptエンジンを使ってJSONをパースする方法もあるので紹介しておきます

JScriptはWindowsに最初から入っているスクリプト実行の仕組みで、これを ScriptControl という部品から呼び出すと、JavaScriptの JSON.parse をVBAから間接的に使えます

Sub ParseByJScript()
    Dim sc As Object
    Dim jsonText As String
    Dim parsed As Object

    jsonText = "{""name"":""Javeo"",""height"":180}"

    ' JScriptエンジンを用意
    Set sc = CreateObject("ScriptControl")
    sc.Language = "JScript"

    ' JavaScriptのJSON.parseで解析
    Set parsed = sc.Eval("(" & jsonText & ")")

    ' プロパティ名で値を取り出す
    Debug.Print parsed.name   ' → Javeo
    Debug.Print parsed.height ' → 180
End Sub

この方法のメリットは、外部ライブラリのインポートが要らないことです

ただ、いくつか弱点もあって、正直なところ常用にはVBA-JSONのほうが向いています

• ScriptControl は32bit版のOfficeでしか動かない(64bit版では別の書き方が必要)
• 取り出した値の扱い(配列やネスト)がVBA-JSONより少しクセがある
• Macでは使えない

なので個人的には、基本はVBA-JSON、どうしてもライブラリを足せない事情があるときだけJScriptという使い分けがおすすめです

VBA-JSONのよくあるつまずき・FAQ

VBA-JSONでハマりやすいポイントを、質問形式でまとめておきます、エラーが出たらまずここを確認してみてください

「ユーザー定義型は定義されていません」と出る

これは 参照設定の漏れがほぼ原因です

VBA-JSONはDictionaryを使うので、WindowsのExcelなら「ツール → 参照設定」で Microsoft Scripting Runtime にチェックが入っているか確認してください、入っていなければチェックを入れて保存し、もう一度実行すれば直ります

MacのExcelの場合は、前述のVBA-Dictionary(Dictionary.cls)を取り込んでいるかを確認しましょう

「KeyNotFoundError」のようなエラーが出る

これは、JSONに存在しないキー名を指定して取り出そうとしたときに出るエラーです

キー名のタイプミス、大文字小文字の違い、そもそもそのキーが無いJSONだった、あたりが定番の原因ですね

このエラーはハマりやすいので、原因の切り分けと対処法を VBA-JSONでKeyNotFoundErrorが発生するときの対処をまとめた記事 で別途くわしく解説しています、同じエラーで止まっている方はそちらをどうぞ

日本語が文字化けする

Web APIから取得したJSONの日本語が文字化けする場合は、文字コードの取り違えが原因のことが多いです

多くのAPIはUTF-8で返してくるので、responseText をそのまま使うとShift_JIS環境で化けることがあります、その場合は responseBody(バイト列)を取得して、UTF-8として読み直すと直ります

Dim stream As Object
Set stream = CreateObject("ADODB.Stream")
stream.Open
stream.Type = 1               ' バイナリ
stream.Write http.responseBody
stream.Position = 0
stream.Type = 2               ' テキスト
stream.Charset = "UTF-8"       ' UTF-8として読み直す
jsonText = stream.ReadText
stream.Close

キーがあるか分からないとき、どう書けばいい？

キーが存在するか不安なときは、取り出す前に .Exists でチェックすると安全です(Dictionaryの機能です)

If parsedData(1).Exists("weight") Then
    Debug.Print parsedData(1)("weight")
Else
    Debug.Print "weightキーはありません"
End If

これを挟んでおくと、キーが無いJSONが来てもエラーで止まらずに処理を続けられます

VBA-JSONの活用例

導入と使い方が分かったところで、「で、実際どんなことに使えるの？」というイメージを少し具体的にしておきます

いちばん多いのは、やはり Web APIのレスポンス(JSON)をパースしてシートに展開するパターンです、為替レート・天気・在庫情報みたいな「外部の最新データ」をExcelに自動で取り込めると、手作業のコピペがまるごと無くなります

たとえばフリマやECのAPIを叩いて、出品データや売上をExcelに集計する、みたいな使い方ですね、APIへリクエストを送る具体的な書き方は eBay APIにVBAでリクエストを送る方法の記事 にまとめているので、JSONパースと組み合わせると一通りの流れがつかめます

逆に ConvertToJson 側だと、VBAで組み立てたデータをJSONにして、メール本文やAPIのリクエストボディに載せる、といった使い方ができます、VBAから自動でメールを送る仕組みは VBAでGmailを送信する方法の記事 で扱っているので、データ生成と通知を組み合わせたい方はあわせてどうぞ

そもそもVBA自体がはじめてで「Dim とか For Each の書き方からあやしい…」という方は、先に VBA入門の記事 で基礎をさらっておくと、この記事のコードもぐっと読みやすくなると思います

AIにVBA-JSONのコードを書いてもらうコツ

最近はClaudeやChatGPTにVBAコードを書いてもらう人も増えてきました、もちろんVBA-JSONを使ったコードも、頼めば書いてくれます

ただ、AIにそのまま「VBAでJSONをパースして」と頼むと、意図しない実装を返してくることがあるんですよね

• VBA-JSONを使わず、自前のJSON解析関数をゼロから書こうとする
• 参照設定の前提がズレていて、そのままだと動かないコードを返す
• 標準機能だけで無理やり読もうとして、やたら長いコードになる

こうしたズレを避けるには、依頼するときに次のような前提を明示するのがおすすめです

VBAで○○のJSONデータをパースするコードを書いてほしい
前提:
- VBA-JSON(JsonConverter.bas)を導入済み
- ParseJson の戻り値を Dictionary / Collection として直接扱う
- 参照設定は Microsoft Scripting Runtime を入れている前提
- 配列は番号、オブジェクトはキー名でアクセスする形で

エラーが出たときも、コードとエラーメッセージをまとめて貼り付ければ、AIが原因と対処をだいたい提示してくれます、自分でハマる時間がかなり減らせるので、これは活用しない手はないです

ClaudeでVBAコードを書いてもらう基本的な流れは Claudeの使い方を初心者向けに解説した記事 にまとめているので、AIにコードを頼むのが初めての方は、そちらから読むとスムーズだと思います

まとめ

VBA-JSONを使えば、これまでVBAでは扱いにくかったJSONが、ぐっと身近になります

導入のポイントはこの2つだけです

• JsonConverter.bas をVBEにインポートする
• Microsoft Scripting Runtime に参照設定する(Macは VBA-Dictionary)

使い方も、覚える関数は2つだけです

• JSONを読み込むなら ParseJson(配列は番号、オブジェクトはキー名で取り出す)
• JSONを書き出すなら ConvertToJson(「{ }」はDictionary、「[ ]」はCollectionで組む)

この導入2ステップと関数2つさえ押さえれば、Web APIとの連携をはじめ、VBAでできることの幅がかなり広がります

まずは手元の短いJSONを ParseJson に通して、Debug.Print で1個取り出してみるところから始めると、感覚がつかみやすいと思います

Claude Code Desktopを使い始めるとき、最初にぶつかる不安が「これって、勝手にファイル消されたりしないの？」「うっかりパスワード漏らさない？」という疑問じゃないでしょうか

結論から言うと、初期設定でちゃんと枠を作っておけば、かなり安心して使えるようになります

この記事では、Claude Code Desktopを始める非IT職の方向けに 最初の15分でやっておきたい最低限のセキュリティ対策を5つにまとめました

難しいプログラミング知識は不要、コピペで使える設定例も載せています

Claude自体の基本的な使い方はClaudeの使い方を初心者向けに解説した記事でまとめているので、まずそちらから読むとスムーズです

なぜClaude Code Desktopにセキュリティ対策が必要なのか

Claude Code Desktopはとても便利で、自分の代わりにファイルを読んだり、コードを書いたり、PCの中で色々な作業をしてくれます

でも裏を返すと、そこまでの権限をAIに渡しているということでもあります

もし何も設定せずに使っていると、たとえばこんなリスクがあります

• うっかり大事なファイルを削除されてしまう
• WordPressのパスワードがコードに書き込まれてGitHubに公開される
• 「やり直して」と言ったらgitの履歴が一気に消える
• 悪意のあるWebサイトを読み込んで、変な指示に従ってしまう

怖い話に聞こえるかもしれませんが、これは 初期設定をちゃんとやれば、ほぼ全部防げる話です

Claude Code Desktopのセキュリティは、ざっくり次の3層構造で守ります

1. 権限設定（settings.json）:「これはやらせない」を機械的に決める
2. プロジェクト指示（CLAUDE.md）：「こういう方針で動いてね」とAIにお願いする
3. 運用のルール：パスワードはコードに書かない、確認してからコミットするなど

本記事ではこの3層を、ひとつずつ整えていきます

対策1：設定ファイル「settings.json」の場所と用語を理解する

まずはClaude Code Desktopの本丸、権限を決める設定ファイルについて理解します

設定ファイルは3か所ある

Claude Code Desktopの権限設定は settings.json というJSONファイルに書きます、場所は次の3つです

個人ブログ運営のような自分1人の作業なら、まずは ~/.claude/settings.json（ユーザーフォルダ共通）に基本ルールを書いておけばOKです

ちなみに「JSONファイルを編集するのは怖い」という方は、Claudeに頼んで編集してもらうのが一番楽です、「~/.claude/settings.json に○○の設定を追加して」とお願いすればClaude Code Desktop自身がやってくれます

用語：allow / ask / deny / Bash とは

権限設定では、Claudeにやらせる操作を3つの態度に分けます

• allow（許可）：何も聞かずに実行してOK、安全な作業に使う
• ask（確認）：実行する前に「やってもいい？」と一度聞いてくる
• deny（拒否）:機械的に実行を止める、最強の鍵

そして「Bash」というのは、Claudeが裏で実行するコマンド（プログラム命令）のことです

自分で直接打つわけではなく、Claudeに「○○して」とお願いしたときに Claudeが必要に応じて使う仕組み、と思っておけば十分です

たとえば Bash(rm *) と書くと「Claudeが rm という削除コマンドを使おうとする操作」を指します

ファイル操作なら Read（読み込み）、Edit（編集）、Write（書き込み）といった種類もあります

このあと出てくる設定例を見るとイメージ湧くと思います

対策2：秘密の情報（パスワード・APIキー）を守る3ステップ

WordPressのパスワードや各種APIキー、こういう 秘密情報の漏えいはClaude Code Desktop利用時の事故で一番起きやすいトラブルです

守り方は3ステップで完結します

ステップ1：秘密情報は「.envファイル」に集約する

.env（ドット・イー・エヌ・ブイ）というファイル名で、プロジェクトフォルダの中に作ります

WP_BASE_URL=https://example.com
WP_USERNAME=admin
WP_APP_PASSWORD=xxxx xxxx xxxx xxxx xxxx xxxx
OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxxxxxx

ポイントは パスワードやAPIキーを直接コードに書かない、そして このファイルだけにまとめておくこと

コードからはこのファイルを読み込むようにしておけば、後でパスワードを変えるときも .env を書き換えるだけで済みます

ステップ2：「.gitignore」でGitに含めない

.gitignore（ドット・ギット・イグノア）はGitに 「このファイルは管理しないでね（=GitHubにもアップしないでね）」と伝えるためのリストです

.env
.env.local
.env.*
/secrets/

これを入れておくと、うっかり git add や git push しても .env はGitHubに送信されません

逆にこれを忘れて公開リポジトリにパスワードを上げると 数分以内にbotが拾って悪用されることもあるくらいなので、最初に入れておくのを強く推奨します

ステップ3：settings.jsonでClaudeに読ませない

最後に、Claude自身が .env や秘密鍵を読まないように settings.json でブロックします

{
  "respectGitignore": true,
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(./secrets/**)",
      "Read(./**/*.pem)",
      "Read(./**/*.key)",
      "Read(./**/id_rsa)",
      "Read(./**/credentials.json)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)"
    ]
  }
}

こうしておけば 「.envの中身を見せて」とお願いしてもClaude側でブロックされます

リストには .env 系のほかに、.pem や .key といった秘密鍵ファイル、SSH接続用の id_rsa、Googleサービスで使われる credentials.json、SSH鍵フォルダやAWS認証情報フォルダなど、各種認証ファイルをまとめて拒否しています

うっかり「.envを開いて」「秘密鍵見せて」みたいなことが起きても、ここで止まる仕組みです

1行目の "respectGitignore": true はちょっと違うタイプの設定で、.gitignore に書いたファイルをClaudeのファイル選択画面から自動的に除外する機能を有効にします

ステップ2で .gitignore に登録した .env などが、そもそもClaudeの目に触れる場面を減らせる効果があります（デフォルトで true ですが、明示しておくと意図が伝わって安心です）

「.claudeignore」は公式じゃないので使わない

古い記事や一部のSNSで「.claudeignore というファイルを置けば除外できる」という情報を見かけますが、これは 2026年5月時点でAnthropic公式にはサポートされていません

Claude自身が「.claudeignore がある」と幻覚を起こすケースまであるくらいで、書いても効かないので注意

除外設定は settings.json の permissions.deny でやるのが正解です

対策3：危険な操作からプロジェクトを守る

次は「やられたら困る」コマンド系の防御です

自分が直接打つわけではないですが、Claudeが裏でやろうとする操作を制限する設定です

最低限denyしておきたいコマンド

{
  "permissions": {
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git reset --hard*)",
      "Bash(git push --force*)",
      "Bash(git push -f*)",
      "Bash(DROP TABLE*)",
      "Bash(DELETE FROM*)"
    ],
    "ask": [
      "Bash(git push*)",
      "Bash(rm*)"
    ]
  }
}

それぞれが何を防ぐのかは下の表を見てください

「自分はそんなコマンド打たないから関係ないかも」と思うかもしれませんが、Claudeに「整理して」「やり直して」とお願いした時に裏でこれらが動く可能性があります

表の上3つは個人ブログ運営でも普通に出てくる話なので、特に押さえておきたいところです

便利だけど危険な設定

Claude Code Desktopの設定画面に 「バイパス権限モードを許可」というトグルがあります

名前のとおり すべての権限チェック（denyやaskを含む）をバイパスして、Claudeを中断なく動作させるための設定です

確かにlintエラーの修正やボイラープレートコード生成のような「安全と判断できる繰り返し作業」を快適にこなせる便利な機能で、画面の説明文にもそういった用途が書かれています

ただし同じ画面に 「データ損失、システム破損、またはデータ流出（プロンプトインジェクション攻撃など）を引き起こす可能性」と明記されているとおり、リスクのほうがはるかに大きい設定です

この設定をONにすると、画面下のモード切替メニューに 「許可をバイパス」モードが選択肢として現れる仕組みで、OFFの間は同じ位置にグレーアウトで表示されています

つまり このトグル自体が、危険モードを使えるかどうかの鍵になっているわけです、ONにしないことを強く推奨します

慣れて油断したタイミングほど事故が起きるので、面倒さよりリスクのほうが圧倒的に大きいです

「毎回確認が面倒だから」と感じる場合は、代わりに 「自動モード」を選ぶのがおすすめです

参考までに、画面下のモード切替メニューの中身はこんな感じです

自動モードは denyルールは守りつつ、多くの操作を自動進行してくれるモードなので、ガードレールを保ったまま快適に使えるバランスの良い選択肢になります

対策4：CLAUDE.mdで「お願いごと」を伝える

権限設定だけでなく、もう一段の保険として CLAUDE.md というファイルにルールを書いておきます

CLAUDE.mdの位置づけ

CLAUDE.md はプロジェクトフォルダの直下に置く Claudeへの常時指示書です

Claude Code Desktopが起動するたびに自動で読み込まれて、会話中の判断のベースになります

ただし注意点として、CLAUDE.md はあくまで 「お願いベース」です

settings.json のdenyのように機械的にブロックされる強制力はなく、Claudeが「これは例外的にやってもいいかな」と判断することもあります

なので 機械的に止めたいことは settings.json のdenyに書く、方針として伝えたいことは CLAUDE.md に書く、というすみ分けで考えてください

コピペで使えるCLAUDE.mdテンプレート

# プロジェクト方針

## 秘密情報の扱い
- APIキー・パスワードは原則 `.env` ファイルに入れる、コードに直接書かない
- `.env` の中身を画面に表示しない（cat や echo で出さない）
- ID・パスワードらしき文字列を見つけたら、コードに書く前に私に確認する

## ファイル操作
- ファイル削除は私の明示的な指示があるまでしない
- 削除する場合も、まず削除対象のリストを見せて確認を取ってから実行する

## Git操作
- main / master ブランチへの直接コミット・pushはしない、原則として別ブランチで作業する
- `git push` する前に「pushしていいですか？」と一度確認する

## 動作確認
- コードを変更したあとは、動作確認の手順を提示する
- 確認が取れていない変更を「完了」と報告しない

このテンプレを CLAUDE.md として保存して、プロジェクトフォルダに置くだけでOKです

自分の運用に合わせて項目を増やしたり、文言を調整したりして使ってください

ID・パスワードの自動検知について

「コードに秘密情報を入れようとしたら自動で止めてほしい」というニーズはよくあるのですが、Claude Code Desktop単体ではそういう自動検知機能はありません

上のテンプレに含めた「ID・パスワードらしき文字列を見つけたら確認する」という指示で ある程度は気づいてもらえます

ただし完璧ではないので、本格的に防ぎたい場合は Gitleaks や truffleHog といった専用ツールを併用するのが本筋になります（これは中級者向けなので別記事で扱います）

対策5：もう一歩進んだ安全策（＋α編）

ここまでの4つで最低限の防御はできているので、ここから先は 慣れてきたら追加で検討するものとして軽く紹介します

Plan Modeで事前確認

Claude Code Desktopには「Plan Mode」というモードがあります

これを有効にすると、Claudeは 実行する前に「こういう手順でやろうと思います」という計画だけを提示してくれて、こちらがOKを出すまで実際の作業には進みません

大きな変更や、初めての種類の作業のときには特におすすめです、Shift+Tabキーで切り替えられます

Hooksで自動チェック

「Hooks」は Claudeが何かする前後に自動で動く小さなスクリプトを仕込む機能です

たとえば「Claudeがコマンドを実行する直前に、危ないキーワードが含まれていたらブロックする」といった自動チェックを差し込めます

スクリプトを書く知識が必要になるので、これは本格的に運用したくなってきた頃の選択肢として覚えておく感じでOKです

サンドボックスで隔離する

「サンドボックス」は Claudeが触れる範囲を仮想的な囲いの中だけに制限する仕組みです

万一おかしな動きをしても、囲いの外には影響しないので安心度が一段上がります

ただし設定するにはDockerなどの専門ツールが必要で、非IT職の方やバイブコーディング的にサクッと使いたい方には少しハードルが高めです

「権限設定とCLAUDE.mdだけだとちょっと不安、もう一段固めたい」と感じたら検討する選択肢、くらいの位置づけで覚えておけば十分です

おまけ｜実はこれ全部Claudeに頼めます

ここまで読んで「いろいろ設定があって面倒そう」と感じた方、安心してください

実はこの記事で紹介した設定、ほとんどClaude Code Desktop自身にお願いできます、JSONファイルの編集なんて普段やらない人には腰が引ける作業ですが、AIに頼めば数分で全部終わります

Claudeに頼めること

• settings.json への deny や respectGitignore の追加
• .gitignore の作成と中身の追加
• CLAUDE.md のテンプレート作成
• .env.example（認証情報の枠だけ）の作成

コピペで使える依頼テンプレート

たとえばこんな感じで頼めばOKです

このプロジェクトのセキュリティ初期設定をしてほしい

1. ~/.claude/settings.json に以下を追加
   - "respectGitignore": true
   - .env や秘密鍵系（.pem / .key / id_rsa / credentials.json）の Read を deny

2. このプロジェクトに .gitignore を作って次を追加
   - .env / .env.local / .env.*
   - /secrets/

3. このプロジェクトに CLAUDE.md を作って次の方針を書く
   - 秘密情報の扱い（APIキー・パスワードは .env に集約、コードに直書きしない）
   - ファイル削除は明示的な指示があるまでしない
   - git push 前に確認を取る

4. .env.example を作って必要な環境変数の枠（値は空でOK）を用意

設定内容はそれぞれ私に提示してから書き込んでね

最後の 「設定内容はそれぞれ私に提示してから書き込んでね」がポイントです、変な設定が紛れ込まないよう一度確認できます

自分でやる必要があるもの

• .env の実際の値（パスワード・APIキー）：Claudeに値を入れさせると架空の文字列で埋めてしまうことがあるので、自分でコピペするのが安全
• 「バイパス権限モードを許可」トグル：GUI設定なのでClaudeでは触れない、デフォルトOFFなので「触らない」だけでOK

それでも理屈を先に学ぶべき理由

ここまで読んで「Claudeに頼めるなら、この記事を最初から読まなくてもよかったのでは?」と思うかもしれません

でも実は、記事で紹介した 「何のために何をやっているか」が分かっていることが大事です

Claudeも完璧ではないので、頼んだ内容と微妙に違う設定が出てくることもあります、そのとき 「想定通りか」を自分の目で確認できるのは、ここまで読んだ人だけの強みです

逆に「中身わからないけど全部任せた」状態だと、おかしな設定が混ざっていても気付けません

記事の知識 + Claudeへの依頼、この組み合わせが一番安全で速いやり方になります

まとめ｜最初の15分でやる5つの設定

長くなりましたが、要点を整理するとこんな感じです

1. settings.jsonで権限設定の仕組みを理解する（allow / ask / deny）
2. 秘密情報は.env + .gitignore + settings.jsonのdenyの3段構えで守る
3. rm -rf や git push –force などClaudeが裏で使う危険な操作をdenyに登録する
4. CLAUDE.mdでAIへの方針（お願いごと）を明文化する
5. 慣れてきたらPlan Mode・Hooks・サンドボックスなどで一段守りを固める

ポイントは 「機械的に止めたいこと」と「方針として伝えたいこと」をきっちり分けること

前者は settings.json のdenyで機械的にブロック、後者は CLAUDE.md でお願い、この使い分けができれば最低限のガードレールは整います

そして個人的に大事だと思うのが、「設定したから安心」じゃなくて、変更内容は毎回ちゃんと自分でレビューすること

AIが書いたコードや実行しようとする操作を、最後に自分の目で確認する習慣を持っておくと、設定の網を抜けた問題にも気付けます

Claude Code Desktopはとても強力なツールなので、安全に使う枠組みを最初に作っておけば、長く快適に付き合えると思います

Claude自体の基本的な使い方はこちらの記事で解説しているので、まだの方はぜひ合わせてどうぞ

変数

変数とは

変数が何かというとその名の通り”中身が変わる数（値）”のことを指します

計算結果や文字列、オブジェクトなどを一時的に格納して利用しますがExcel作業に例えると、セルに値を入力して必要なときに参照するイメージに近いです

変数を使う目的

変数を使う一番の目的は、”プログラムの中で扱う値を一時的に記憶し、再利用できるようにすること“です

もし変数を使わずに直接セルや数値を書き込むだけだと、同じ処理を繰り返すときに毎回手直しが必要になり、コードの柔軟性が失われます

変数を使うことで以下のメリットがあります

• 処理の効率化：一度計算した値を保存し、繰り返し利用できる
• 保守性の向上：変更が必要な場合、変数の値を変えるだけで済む
• 可読性の向上：意味のある名前をつけることで、コードを読んだ人が目的を理解しやすい
• 一時的なデータ保持：途中計算の結果やフラグ（条件判定用のTrue/Falseなど）を保持する

変数の書き方

VBAで変数を宣言する場合の基本形は”Dim 変数名 As データ型“です

Dim score As Integer
Dim name As String

• Dim … 変数を宣言するためのキーワード
• 変数名 … 値を格納する箱の名前　※後述の命名規則を要確認
• データ型 … その変数にどの種類のデータを入れるか指定

変数の命名規則

VBAは柔軟なプログラムなので実は日本語を変数名にすることもできます・・・が、一般的には英語で書きますし他の言語では受け入れられないのがほぼなのでまずは英語で書きましょう

そしてVBAで多く使われるのはキャメルケースでハンガリアン記法の利用もボチボチ

他がNGってわけでもないですが一般的な記述にすることで可読性と保守性が上がるのでなるべく合わせましょう

Dim targetRow As Long   ' ---キャメルケース
Dim lngRow As Long      ' ---ハンガリアン記法
Dim target_row As Long  ' ---スネークケース 
Dim TargetRow As Long   ' ---パスカルケース
Dim 対象行 As Long       ' ---日本語は非推奨

変数のスコープ

変数にはスコープと言われる考え方がありまして、Dimの代わりに”Private/Public“で宣言することで使える範囲が変わります

範囲の考え方はおおきくわけて2つ

• 同一プロジェクト内（≒Excelファイル）でモジュールを跨いで利用することができるか・・・①②
• 同一モジュール内でプロシージャを跨いで利用できるか・・・③④

宣言する場所による違い（プロシージャ内外）

プロシージャ外で宣言すると同一モジュール内の全プロシージャで変数が利用できるようになり、変数の値はプロシージャを跨いでも保持されます

プロシージャ内で宣言すると同一プロシージャの中だけで利用できるようになります

プロシージャ外で宣言する場合のPrivete/Publicステートメント

プロシージャ外で宣言する場合はDimの代わりにPrivateとPublicも利用できます

修飾子	スコープ	他モジュールからアクセス
Private	モジュール内限定	不可
Public	プロジェクト全体	可能

データ型について

変数は”文字”や”数字”などデータの型を指定することができます

指定しないことも可能ですが、プログラムでは数字の100（ひゃく）と文字の100（いちぜろぜろ）は違うのでエラー・バグの温床になってしまうため原則指定します

基本的なデータ型

まずは基本になる様々な”値“を取り扱う時に指定するデータ型から

Integerは使われるところをよく見かけますが、Longが上位互換みたいなものなので使う必要が無いって意味で使用頻度は”低”にしています

オブジェクト型について

基本形と違って”値”ではなくデータの箱のようなものを格納するオブジェクト型がありまして、このオブジェクト型は何か一つのことを指すわけではなく”Workbook（ブック）“、”Worksheet（シート）“、”Range（セル）“などをまとめてオブジェクト型と呼びます

種類は無数にあるのでここでは触れませんが、VBAを利用していれば嫌でも出会うので細かい話はサンプルプログラムの説明などで

ちなみにオブジェクト型に代入するときはSetステートメントが必要なので利用時にはご注意を

Dim name As String
Dim wb As Workbook

name = 'ジャベ雄'
Set wb = Thisworkbook ' ---オブジェクトへの代入はSetから始める

なるべく使用を控えたいけど便利な万能データ型

データ型の冒頭で触れたデータ型を”指定しない”時に関連しますが、データ型の一つに万能型の”Variant“がありまして、指定しない場合はこの万能型が適用されます

もう一つオブジェクト型なら何でも入る”Object“があります

ObjectはVariantでも代用できないわけではないですが、なるべくデータ型は指定する思想があるので最低限使い分けはしたいところ

Variant型（データ型を指定しない）はなるべく避けたいとことですが、Arrayなど一部Variantでしか取り扱えない場合や、プログラムの中でどのデータ型になるかわからない場合があるので状況に応じて利用しましょう

列挙型（Enum）とユーザー定義データ型（Type）

イレギュラー枠でEnumとTypeがありまして、EnumはLongの集合体、Typeは変数を束ねると考えるとしっくりきます

これも奥が深いのでここでは紹介だけまでにして、サンプルソース置くのでこんなのもあるんだーぐらいでどうぞ

Enum WeekDay
    Sunday      ' 0
    Monday      ' 1
    Tuesday     ' 2
    Wednesday   ' 3
    Thursday    ' 4
    Friday      ' 5
    Saturday    ' 6
End Enum

Sub ShowDay()
    MsgBox "今日の曜日は: " & WeekDay.Monday  ' 結果は「1」
End Sub

Type Employee
    Name As String
    Age As Integer
    Salary As Double
End Type

Sub ShowEmployee()
    Dim emp As Employee
    emp.Name = "田中 太郎"
    emp.Age = 30
    emp.Salary = 5000000

    MsgBox "氏名: " & emp.Name & vbCrLf & _
           "年齢: " & emp.Age & vbCrLf & _
           "給与: " & emp.Salary & "円"
End Sub

定数

定数とは

定数は”中身を定めたわる数（値）”のことを指します

基本的な使い方は変数と同じですが違いがあるところだけピックアップします

定数を使う目的

定数の目的は、決して変わらない値をプログラム中で安全に使うことです

例えば消費税率や基準日などをいつか一括で修正する可能性がある値は、後から修正するときに見落としやすく、バグの原因になります

その他にも定数を使うことで以下のメリットがあります

• 安全性の確保：プログラム実行中に誤って値を書き換えられる心配がない
• 変更管理が容易：消費税率などを1か所変更すればプログラム全体に反映できる
• 可読性の向上：「0.1」より「TAX_RATE」のような名前を使うことで意味が明確になる
• 保守性の向上：長期的に見ても管理がしやすく、他人がコードを読んだときも理解しやすい

定数の書き方

VBAで定数を宣言する場合の基本形は”Const 変数名 As データ型 = 値“です

Const score As Integer = 100
Const name As String = "ジャベ雄"

変数と違って宣言と同時に値を決めてその後編集不可になります

定数の命名規則

変数と同じように一般的に使われる命名規則がありまして、全て大文字のスネークケースで一見して意味が分かる単語を結合します

Const MAX_USER_COUNT As Integer = 100
Const DEFAULT_FONT_SIZE As Double = 12.5
Const API_ENDPOINT_URL As String = "https://example.com/api"

まとめ

結構初歩の部分ですがまとめ始めるとなかなかのボリュームになってしまいました

良くも悪くもシステムとしての制限がないので自分でやチームでルールを作って安定運用できるプログラム作成を心がけましょう！

[temp id=2]

VBAを始める前に

VBAを始める前にまずVBAの概要とExcelの準備です

VBAとは

VBA（Visual Basic for Applications）は、Microsoft 365・Office製品（Excel、Accessなど）で使用できるプログラミング言語です

よくVBAとマクロの違いみたいな話を見ますがマクロは機能名でVBAはその中身って感じで会話の中では同じものとして扱って大丈夫かなと

VBAを使いこなせば、これまで何時間もかかっていた作業がボタン一つで一瞬で終わる、なんてことも夢ではありません

開発者タブを表示しよう

ExcelでVBA始めるならまず開発タブを表示しましょう

正直慣れるとVBEの画面は”Alt+F11“で開くしマクロは”Alt+F8“で実行しちゃうので使う頻度は減りますが最初はあったほうが便利です

VBAで押さえておきたい基本

VBAを学ぶ上で、最低限知っておきたい基本的な概念をいくつか紹介します

最初は難しく感じるかもしれませんが、深堀は別でやりますので今は「こういうものがあるんだな」くらいの気持ちで読み進めてください

変数と定数

プログラミングでは、データ（数値や文字列など）を一時的に保存しておくための「箱」のようなものを使いますが、この箱のことを変数や定数と呼びます

Sub test()
Const tax_rate As Double = 0.1 '---税率
Dim price_excluding_tax As Long '---税抜き価格
Dim price_including_tax As Long '---税込み価格

price_excluding_tax = 1980
price_including_tax = price_excluding_tax * (1 + tax_rate)
Debug.Print (price_including_tax)
End Sub

データ型

変数や定数には、どんな種類のデータを入れるかをあらかじめ決めておく必要があり、これをデータ型と呼びます

例えば、数値を扱うのか、文字を扱うのか、日付を扱うのか、といった区別です

条件分岐、ループ処理などのフロー制御

プログラムは基本的に上から下へ順番に実行されますが、フロー制御を使うことで状況に応じて処理の流れを変えることができます

' A1～A10のセルの中で300以上の数字だったら文字を赤くする
Sub test()
Dim i As Long
For i = 1 To 10
    If Cells(i, 1).Value >= 300 Then
        Cells(i, 1).Font.Color = RGB(255, 0, 0)
    End If
Next
End Sub

メインプロシージャとサブプロシージャ

VBAでは、一連の処理のまとまりをプロシージャと呼びます

機能や仕組みではなく、役割や考え方みたいな位置づけなので必ずしもこの二つが必要ってわけではなく簡単なプログラムならプロシージャー1つなんてことも多々ありますし、サブプロシージャーのさらにサブプロシージャーを作ったりすることもあります

車でいうとメインプロシージャが車の組み立て、サブプロシージャーが各部品の作成のイメージですね

Sub MainProcedure()
    Debug.Print ("これがメインプロシージャーです")
    Call SubProcedure1
    Call SubProcedure2
End Sub
Sub SubProcedure1()
    Debug.Print ("これがメインプロシージャー1です")
End Sub
Sub SubProcedure2()
    Debug.Print ("これがメインプロシージャー2です")
End Sub

可読性の重要性

VBAは自分だけでなく、他の人がコードを読む（または将来の自分が見返す）可能性もあります

誰が見ても分かりやすい、可読性の高いコードを書くことは非常に重要です

インデントについて

インデントとは、行頭の字下げのことで処理の塊（ブロック）を視覚的に分かりやすくするために行います

If文やFor文などフロー制御の中の処理は、インデントを下げるのが一般的です

' 悪い例
If Range("A1").Value > 10 Then
MsgBox "10より大きいです"
End If

' 良い例
If Range("A1").Value > 10 Then
    MsgBox "10より大きいです"
End If

変数などの命名規則について

変数やプロシージャの名前は、その役割がひと目で分かるように付けることが大切です

例えば、”a"や”b"のような無意味な名前ではなく、"userName"（ユーザー名）や"calculateTotalPrice"（合計金額を計算する）のように一見して意味が分かるようにすることが望ましいです

書き方にも規則性がありまして”定数は全て大文字にする”、”プレフィックスでデータ型を示す”、”単語を特定の文字で繋ぐ”などなど言語や時代によって変化はありますが少なくとも一つのプログラムの中では一貫したルールにすべきです

モジュールの種類

VBAのコードを記述する場所をモジュールと呼びます

モジュールにはいくつか種類がありますが、初心者がまず覚えておくべきなのは以下の2つです

まとめ

今回は、VBAの魅力とその基本的な概念についてお話ししました。最初は覚えることが多くて大変に感じるかもしれませんが、一つ一つは決して難しいものではありません。

VBAを学ぶ最大のメリットは、日々の業務に直結するスキルであるということです。学習したことがすぐに実践で活かせ、成果が目に見えやすいので、モチベーションを維持しやすいのも特徴です。

このブログでは、今後もVBAの具体的な書き方や便利なテクニックをどんどん紹介していきます。ぜひ、次回の記事もチェックして、退屈な繰り返し作業から解放され、より創造的な仕事に時間を使えるようになりましょう！

[temp id=2]

Seleniumでブラウザを自動操作していると、「要素がまだ読み込まれていなくてエラーになる」という場面によく出会います

そんなとき time.sleep() で適当に待つ人も多いですが、これだと待ちすぎたり待ち足りなかったりで安定しないんですよね

結論から言うと、Seleniumの待機は time.sleep ではなく WebDriverWait と expected_conditions の組み合わせが確実です

「条件が満たされたら、その瞬間に次へ進む」という待ち方ができるので、無駄もなければ取りこぼしもないんです

この記事では WebDriverWait の基本の書き方から、条件を指定する expected_conditions の一覧、さらに各条件がSeleniumの内部でどう動いているかまで、じっくり解説していきます

後半は全条件のリファレンスになっているので、「あの条件どう書くんだっけ」というときの辞書としても使ってくださいね

WebDriverWait について

WebDriverWait は、指定した条件を満たすまで待機してくれる便利なモジュールです

Seleniumでブラウザを操作するとき、特定の条件が整うまで待ちたいシーンってすごく多いんですよね

そこで time.sleep() でxx秒待つようにすると、長すぎれば無駄が多く、短すぎればエラーになりがちで、けっこう雑なプログラムになってしまいます

そういう意味で、WebDriverWait はほぼ必須レベルの存在だと思っています

ちなみに経験上、WebDriverWait だけではうまくいかない場面もあって、最後に0.5秒ほど sleep を足してあげると処理が安定する気がします

基本的なパターンはこちらです

WebDriverWait(webdriver, タイムアウトまでの上限秒数).until(expected_conditionsで設定する条件)

実際にサンプルソースにすると、こんな感じになります

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.common.exceptions import TimeoutException, NoSuchElementException

driver = webdriver.Chrome()
driver.get('https://javeo.jp/practice_scraping/')
try:
    WebDriverWait(driver, 10).until(EC.presence_of_element_located((By.CSS_SELECTOR, '#hoge')))
    print('条件を満たしました')
except TimeoutException:
    print('条件を満たせませんでした')
driver.quit()

import の書き方は expected_conditions を EC という別名で読み込むのが定番です、Selenium 4 でもこの書き方で問題なく動きます

Pythonでは WebDriverWait と expected_conditions は今も標準・現役で、基本パターンはずっと変わっていません、安心して使えますよ

なぜ time.sleep より良いのか

そもそも time.sleep() は「指定した秒数、問答無用で止まる」だけの処理です

import time
time.sleep(5)  # 5秒待つ

ネットワークが遅い日は5秒でも足りず、速い日は0.5秒で表示されているのに5秒待つ、みたいな無駄が出るんですね

一方の WebDriverWait は、条件が満たされた瞬間に次へ進むので、無駄な待ち時間がありません

とはいえ time.sleep も、デバッグ中にちょっと動きを止めて確認したいときなんかには便利なので、完全に使わないわけではないです

「本番の待機には WebDriverWait、確認用にたまに sleep」くらいの距離感がちょうどいいと思います

timeout と poll_frequency

WebDriverWait には、タイムアウトまでの秒数のほかに、チェックの間隔も指定できます

wait = WebDriverWait(driver, timeout=10, poll_frequency=0.5)

• driver: WebDriverのインスタンス
• timeout: 最大待機秒数
• poll_frequency: チェックする間隔(秒)、省略すると0.5秒

つまり「10秒間、0.5秒ごとに条件をチェックする」という設定です

timeout には 10 のような整数秒を渡すのが基本で、Pythonではこの数値指定で問題なく動きます、まずは整数秒で覚えてしまって大丈夫です

ちなみにSelenium 4 以降は、待機時間を datetime.timedelta のような「期間オブジェクト」で扱う流れがあります(Java版などはすでに Duration 指定が中心です)

Python版は今のところ整数秒でも普通に使えるので、ここは「将来的にはそういう流れもある」くらいの認識で十分だと思います

expected_conditions について

WebDriverWait とセットで使うのが、この expected_conditions です

結局のところ expected_conditions が肝心の条件部分で、WebDriverWait はその条件が正常終了 or True になるまで待つだけ、という仕様なんですね

ただこの expected_conditions、良くも悪くも指定できる条件がかなり多くて、使いこなすには事前に把握しておきたいところ、ということでまとめてみました

調べていて気づきましたが、思ったより多くの関数があって、利用シーンが謎なものもチラホラあります

また、expected_conditions の返り値はいろいろありますが、WebDriverWait とセットで使うと、WebDriverWait の仕様上、返り値は正常終了時の値 or エラー(TimeoutException)になります、try-except するときは注意してくださいね

よく使う関数

まずは私が個人的によく使う・使えそうだと思う関数だけをまとめた表です、関数名をクリックすると下のリファレンスに飛べます

正直、最初はこの4つだけで大半のケースは何とかなります

分類別の全関数一覧

続いて、ある程度グループ分けした全関数を、目次のように並べた表です

では、ここから各関数を1つずつ詳しく見ていきます、内部のソースコードも引用しているので、挙動が気になる人はそちらもどうぞ

presence_of_element_located(locator: Tuple[str, str])

引数の locator が DOM に存在していれば、返り値は該当した WebElementを返します(DOMなので画面上に見えるかどうかは問わない)

内部的には find_element で locator の有無を確認しているだけです

def presence_of_element_located(locator: tuple[str, str]) -> Callable[[WebDriverOrWebElement], WebElement]:
    def _predicate(driver: WebDriverOrWebElement):
        return driver.find_element(*locator)

    return _predicate

presence_of_all_elements_located(locator: Tuple[str, str])

引数の locator が DOM に存在していれば、返り値は該当した全ての WebElement を返します(DOMなので画面上に見えるかどうかは問わない)

待機するだけなら presence_of_element_located と同じですね

def presence_of_all_elements_located(locator: tuple[str, str]) -> Callable[[WebDriverOrWebElement], list[WebElement]]:
    def _predicate(driver: WebDriverOrWebElement):
        return driver.find_elements(*locator)

    return _predicate

visibility_of_element_located(locator: Tuple[str, str])

引数の locator が画面上に見えていれば、返り値は該当した WebElementを返します

実態は locator の有無確認と is_displayed() をしているだけです

def visibility_of_element_located(
    locator: tuple[str, str],
) -> Callable[[WebDriverOrWebElement], Union[Literal[False], WebElement]]:
    def _predicate(driver: WebDriverOrWebElement):
        try:
            return _element_if_visible(driver.find_element(*locator))
        except StaleElementReferenceException:
            return False

    return _predicate

def _element_if_visible(element: WebElement, visibility: bool = True) -> Union[Literal[False], WebElement]:
    return element if element.is_displayed() == visibility else False

visibility_of(element: WebElement)

引数の element が画面上に見えていれば、返り値は該当した WebElement を返します

引数にした WebElement がそのまま返り値になるので、単純な待機処理としてしか使うことはなさそうですね

def visibility_of(element: WebElement) -> Callable[[Any], Union[Literal[False], WebElement]]:
    def _predicate(_):
        return _element_if_visible(element)

    return _predicate

visibility_of_all_elements_located(locator: Tuple[str, str])

引数の locator が全て画面上に見えていれば、返り値は該当した全ての WebElement を返します

ただし、locator が1つでも DOM 上に存在しないか非表示(hidden)になっていればエラーになる絶妙仕様なので、使うことはあまりなさそうです

def visibility_of_all_elements_located(
    locator: tuple[str, str],
) -> Callable[[WebDriverOrWebElement], Union[list[WebElement], Literal[False]]]:
    def _predicate(driver: WebDriverOrWebElement):
        try:
            elements = driver.find_elements(*locator)
            for element in elements:
                if _element_if_visible(element, visibility=False):
                    return False
            return elements
        except StaleElementReferenceException:
            return False

    return _predicate

visibility_of_any_elements_located(locator: Tuple[str, str])

引数の locator が画面上に見えていれば、返り値は該当した全ての WebElement を返します

こちらは locator が DOM 上に存在しない場合のみエラーになり、1つでも表示されていれば、表示されている WebElement を返してくれます

def visibility_of_any_elements_located(locator: tuple[str, str]) -> Callable[[WebDriverOrWebElement], list[WebElement]]:
    def _predicate(driver: WebDriverOrWebElement):
        return [element for element in driver.find_elements(*locator) if _element_if_visible(element)]

    return _predicate

invisibility_of_element_located(locator: Union[WebElement, Tuple[str, str]])

visibility_of_element_located の逆で、DOM 上に見えてないことを検知してくれます

DOM 上になければ True、DOM 上にあるけど非表示なら対象の WebElement を返してくれます、ローディング画面が消えるのを待つ、みたいなときに便利ですね

def invisibility_of_element_located(
    locator: Union[WebElement, tuple[str, str]],
) -> Callable[[WebDriverOrWebElement], Union[WebElement, bool]]:
    def _predicate(driver: WebDriverOrWebElement):
        try:
            target = locator
            if not isinstance(target, WebElement):
                target = driver.find_element(*target)
            return _element_if_visible(target, visibility=False)
        except (NoSuchElementException, StaleElementReferenceException):
            # In the case of NoSuchElement, returns true because the element is
            # not present in DOM. The try block checks if the element is present
            # but is invisible.
            # In the case of StaleElementReference, returns true because stale
            # element reference implies that element is no longer visible.
            return True

    return _predicate

invisibility_of_element(element: Union[WebElement, Tuple[str, str]])

実は invisibility_of_element_located のシノニム(別名)です

見ての通り、実は locator でも受け付けできて、invisibility_of_element_located をそのまま返しているだけなんですね

def invisibility_of_element(
    element: Union[WebElement, tuple[str, str]],
) -> Callable[[WebDriverOrWebElement], Union[WebElement, bool]]:
    return invisibility_of_element_located(element)

element_attribute_to_include(locator: Tuple[str, str], attribute_: str)

引数の locator が DOM 上に存在し、さらにそのタグの中に引数の attribute_ 属性があるかで照合します(それ以外はエラー)

使い道としては、JavaScriptで要素が追加されるときぐらいですかね

def element_attribute_to_include(locator: tuple[str, str], attribute_: str) -> Callable[[WebDriverOrWebElement], bool]:
    def _predicate(driver: WebDriverOrWebElement):
        try:
            element_attribute = driver.find_element(*locator).get_attribute(attribute_)
            return element_attribute is not None
        except StaleElementReferenceException:
            return False

    return _predicate

element_located_selection_state_to_be(locator: Tuple[str, str], is_selected: bool)

引数の locator が DOM 上に存在し、さらにその要素の選択状況と引数の is_selected が合っているかで判定を返してくれます

locator が DOM 上に存在しないときはエラーになります

チェックボックスやラジオボタンではない場合、そもそも選択の概念がないので is_selected() は False になります

def element_located_selection_state_to_be(
    locator: tuple[str, str], is_selected: bool
) -> Callable[[WebDriverOrWebElement], bool]:
    def _predicate(driver: WebDriverOrWebElement):
        try:
            element = driver.find_element(*locator)
            return element.is_selected() == is_selected
        except StaleElementReferenceException:
            return False

    return _predicate

element_located_to_be_selected(locator: Tuple[str, str])

引数の locator が選択されている状態であるかで照合します

is_selected() はあまり使う機会がないと思うんですよね

def element_located_to_be_selected(locator: tuple[str, str]) -> Callable[[WebDriverOrWebElement], bool]:
    def _predicate(driver: WebDriverOrWebElement):
        return driver.find_element(*locator).is_selected()

    return _predicate

element_to_be_selected(element: WebElement)

element_located_to_be_selected の引数が locator から WebElement になった版です

def element_to_be_selected(element: WebElement) -> Callable[[Any], bool]:
    def _predicate(_):
        return element.is_selected()

    return _predicate

element_selection_state_to_be(element: WebElement, is_selected: bool)

element_to_be_selected で is_selected() == False が選べるようになっただけです

def element_selection_state_to_be(element: WebElement, is_selected: bool) -> Callable[[Any], bool]:
    def _predicate(_):
        return element.is_selected() == is_selected

    return _predicate

element_to_be_clickable(mark: Union[WebElement, Tuple[str, str]])

まず引数が mark(WebElement と locator のどちらでもOK)になっているのに好感が持てます
※全部そうしてほしい

内部的には visibility_of かつ is_enabled() なので、clickable という名前からチェックボックス向けのような印象を受けますが、input タグなどにも有効です(むしろこっちの方が利用頻度が高い)

def element_to_be_clickable(
    mark: Union[WebElement, tuple[str, str]],
) -> Callable[[WebDriverOrWebElement], Union[Literal[False], WebElement]]:
    # renamed argument to 'mark', to indicate that both locator
    # and WebElement args are valid
    def _predicate(driver: WebDriverOrWebElement):
        target = mark
        if not isinstance(target, WebElement):  # if given locator instead of WebElement
            target = driver.find_element(*target)  # grab element at locator
        element = visibility_of(target)(driver)
        if element and element.is_enabled():
            return element
        return False

    return _predicate

text_to_be_present_in_element(locator: Tuple[str, str], text_: str)

XPATHの [text()=’hoge’] を事前チェックできる感じです

需要がありそうでなさそう、、、で、やっぱりありそうな関数です、「処理が完了しました」のような表示を待つときに便利ですよ

def text_to_be_present_in_element(locator: tuple[str, str], text_: str) -> Callable[[WebDriverOrWebElement], bool]:
    def _predicate(driver: WebDriverOrWebElement):
        try:
            element_text = driver.find_element(*locator).text
            return text_ in element_text
        except StaleElementReferenceException:
            return False

    return _predicate

text_to_be_present_in_element_value(locator: Tuple[str, str], text_: str)

text_to_be_present_in_element を text から value 属性に変えてみました、という関数です

もともと微妙な需要だったのに、さらに下がってる気がします

def text_to_be_present_in_element_value(
    locator: tuple[str, str], text_: str
) -> Callable[[WebDriverOrWebElement], bool]:
    def _predicate(driver: WebDriverOrWebElement):
        try:
            element_text = driver.find_element(*locator).get_attribute("value")
            if element_text is None:
                return False
            return text_ in element_text
        except StaleElementReferenceException:
            return False

    return _predicate

text_to_be_present_in_element_attribute(locator: Tuple[str, str], attribute_: str, text_: str)

text_to_be_present_in_element_value を、value 以外の属性を選べるようにしてみました

じゃあ text_to_be_present_in_element_value いらない・・・となりますね

def text_to_be_present_in_element_attribute(
    locator: tuple[str, str], attribute_: str, text_: str
) -> Callable[[WebDriverOrWebElement], bool]:
    def _predicate(driver: WebDriverOrWebElement):
        try:
            element_text = driver.find_element(*locator).get_attribute(attribute_)
            if element_text is None:
                return False
            return text_ in element_text
        except StaleElementReferenceException:
            return False

    return _predicate

title_is(title: str)

title との完全一致判定です

title 自体ちょっと使いにくいのに、完全一致はなかなか難しい印象です

def title_is(title: str) -> Callable[[WebDriver], bool]:
    def _predicate(driver: WebDriver):
        return driver.title == title

    return _predicate

title_contains(title: str)

こちらは title の部分一致判定です

完全一致よりは現実的だけど、やっぱり title で照合はしないと思います

def title_contains(title: str) -> Callable[[WebDriver], bool]:
    def _predicate(driver: WebDriver):
        return title in driver.title

    return _predicate

url_contains(url: str)

url の部分一致で判定します

個人的には待機処理の条件に url はあまり使わないかなと思います、ただ、ボタンを押してページが切り替わるのを待ちたいときには出番がありますね

def url_contains(url: str) -> Callable[[WebDriver], bool]:
    def _predicate(driver: WebDriver):
        return url in driver.current_url

    return _predicate

url_matches(pattern: str)

こちらは url を正規表現で判定します

URLにIDなどが含まれていて完全一致では指定しづらいとき、正規表現で柔軟に待てるのは便利ですね、ちなみに Selenium 4 で整理された比較的新しい条件です

def url_matches(pattern: str) -> Callable[[WebDriver], bool]:
    def _predicate(driver: WebDriver):
        return re.search(pattern, driver.current_url) is not None

    return _predicate

url_to_be(url: str)

url の完全一致で判定します

遷移先のURLがきっちり決まっているときには使えますよ

def url_to_be(url: str) -> Callable[[WebDriver], bool]:
    def _predicate(driver: WebDriver):
        return url == driver.current_url

    return _predicate

url_changes(url: str)

url の不一致で判定します、指定したURLから変わるまで待つ、という条件ですね

クリック後にページが切り替わるのを待つ、みたいなときに自然に使えます、こちらも Selenium 4 系で整理された条件です

def url_changes(url: str) -> Callable[[WebDriver], bool]:
    def _predicate(driver: WebDriver):
        return url != driver.current_url

    return _predicate

number_of_windows_to_be(num_windows: int)

ウィンドウ(=タブ)の数で照合します

新しいタブが開くのを待ちたいとき以外は、出番が少なめかもしれません

def number_of_windows_to_be(num_windows: int) -> Callable[[WebDriver], bool]:
    def _predicate(driver: WebDriver):
        return len(driver.window_handles) == num_windows

    return _predicate

new_window_is_opened(current_handles: List[str])

新しいウィンドウができるまで待ってくれる、らしいです

number_of_windows_to_be と用途は近いですが、開く前のウィンドウ数を渡しておけば、それより増えたかどうかで判定してくれます

def new_window_is_opened(current_handles: list[str]) -> Callable[[WebDriver], bool]:
    def _predicate(driver: WebDriver):
        return len(driver.window_handles) > len(current_handles)

    return _predicate

frame_to_be_available_and_switch_to_it(locator: Union[Tuple[str, str], str])

指定の frame に移動できるまで待ちます

待機処理としてより、switch_to.frame を安全にする使い方なら需要がありそうです、iframe を操作するときに役立ちますね

def frame_to_be_available_and_switch_to_it(
    locator: Union[tuple[str, str], str, WebElement],
) -> Callable[[WebDriver], bool]:
    def _predicate(driver: WebDriver):
        try:
            if isinstance(locator, Iterable) and not isinstance(locator, str):
                driver.switch_to.frame(driver.find_element(*locator))
            else:
                driver.switch_to.frame(locator)
            return True
        except NoSuchFrameException:
            return False

    return _predicate

staleness_of(element: WebElement)

なんでこんな名前になったのか、、実態は is_enabled だけです、要素が古くなる(DOMから削除される)のを検知できるので、ページ遷移の確認に便利ですね

def staleness_of(element: WebElement) -> Callable[[Any], bool]:
    def _predicate(_):
        try:
            # Calling any method forces a staleness check
            element.is_enabled()
            return False
        except StaleElementReferenceException:
            return True

    return _predicate

alert_is_present()

アラートに遷移できるかを判定します

frame_to_be_available_and_switch_to_it と同じく、待機処理としてより、switch_to.alert を安全にする使い方なら需要がありそうです

def alert_is_present() -> Callable[[WebDriver], Union[Alert, Literal[False]]]:
    def _predicate(driver: WebDriver):
        try:
            return driver.switch_to.alert
        except NoAlertPresentException:
            return False

    return _predicate

any_of(*expected_conditions: Callable[[D], T])

指定した複数の expected_conditions が、1つでも True になればOKという条件です

「成功表示か、エラー表示の、どちらかが出るまで待つ」みたいな分岐に便利です、こちらも Selenium 4 で追加されました

def any_of(*expected_conditions: Callable[[D], T]) -> Callable[[D], Union[Literal[False], T]]:
    def any_of_condition(driver: D):
        for expected_condition in expected_conditions:
            try:
                result = expected_condition(driver)
                if result:
                    return result
            except WebDriverException:
                pass
        return False

    return any_of_condition

all_of(*expected_conditions: Callable[[D], Union[T, Literal[False]]])

こちらは指定した複数の expected_conditions が、全て True になればOKという条件です

複数の条件をまとめてチェックしたいときに使います、any_of とセットで Selenium 4 で追加されました

def all_of(
    *expected_conditions: Callable[[D], Union[T, Literal[False]]],
) -> Callable[[D], Union[list[T], Literal[False]]]:
    def all_of_condition(driver: D):
        results: list[T] = []
        for expected_condition in expected_conditions:
            try:
                result = expected_condition(driver)
                if not result:
                    return False
                results.append(result)
            except WebDriverException:
                return False
        return results

    return all_of_condition

none_of(*expected_conditions: Callable[[D], Any])

こちらは指定した複数の expected_conditions が、1つも True にならなければOKという条件です

「エラー表示が出ないまま処理が進んだか」を確かめたいときなんかに使えます

def none_of(*expected_conditions: Callable[[D], Any]) -> Callable[[D], bool]:
    def none_of_condition(driver: D):
        for expected_condition in expected_conditions:
            try:
                result = expected_condition(driver)
                if result:
                    return False
            except WebDriverException:
                pass
        return True

    return none_of_condition

expected_conditions にない条件は lambda で自作できる

ここまで全関数を見てきましたが、「ちょうどいい条件がない」というケースもあります

そんなときは、until に自作の関数(条件)を渡せます

「driver を受け取って、満たされたら値を返す(満たされなければ False を返す)」関数を渡せばいいだけなので、lambda でサクッと書けるんですね

from selenium.webdriver.common.by import By

# 要素のテキストが空でなくなるまで待つ自作条件
element = WebDriverWait(driver, 10).until(
    lambda d: d.find_element(By.ID, "status") if d.find_element(By.ID, "status").text != "" else False
)

expected_conditions に用意されていない細かい条件で待ちたいときは、この lambda 方式を覚えておくと一気に応用が利きます

そもそも要素の取得自体に迷うときは、Seleniumで要素を取得する find_element の使い方もあわせて読むと、待機とセットでスッキリ書けるようになりますよ

WebDriverWait のよくあるエラーと注意点

TimeoutException が出る

指定した時間内に条件が満たされなかったときに出るエラーです

一番よく見るエラーですね

from selenium.common.exceptions import TimeoutException

try:
    element = WebDriverWait(driver, 10).until(
        EC.presence_of_element_located((By.ID, "main"))
    )
except TimeoutException:
    print("要素が見つかりませんでした")

try-except で囲んで、タイムアウト時の処理を書いておくと安心です

原因としては、セレクタが間違っているか、本当に表示まで時間がかかっているかのどちらかが多いです

要素は見つかるのにクリックできない

presence では見つかるのに、いざクリックするとエラーになることがあります

これは要素は存在するけど、まだ表示されていない・操作できない状態だからですね

そういうときは element_to_be_clickable を使うと解決することが多いです

暗黙的な待機と混ぜると危険

ここは2026年の今でも引っかかる人が多いポイントなので、しっかり押さえておきたいところです

Seleniumには WebDriverWait(明示的な待機)とは別に、implicitly_wait() という「暗黙的な待機」もあります

driver.implicitly_wait(10)  # 要素が見つかるまで最大10秒待つ(全体に適用)

これ自体は楽な仕組みなんですが、WebDriverWait と併用すると、待機時間が予期せず長くなることがあります

これは両方の待機が重なってしまうからです

例えば暗黙的な待機を10秒、明示的な待機を15秒に設定していると、タイムアウトが20秒後に起きる、といった予測しづらい挙動になることがあります

Seleniumの公式ドキュメントでも、暗黙的な待機と明示的な待機は混在させないようにと、はっきり警告されています

個人的には WebDriverWait に統一する派です、条件ごとに細かく待てて、挙動も読みやすいので

こうした自動化スクリプトを実際に動かすときは、ログインや個人情報の扱いなど安全面の配慮も大切です、不安な方は自動化を始める前に知っておきたい安全性の基本もあわせて読んでみてくださいね

あとがき

expected_conditions は、調べてみると知らないだけで多くの関数がありました

presence_of_element_located や visibility_of_element_located は有名ですが、text_to_be_present_in_element や element_to_be_clickable も有用そうで、今後活用してみたいと思います

引数は Tuple 型の locator と WebElement 型の element、どちらでも対応できるパターンがありますが、どうせなら全部どちらにも対応できるパターンにしてほしいところです

ポイントをまとめると、こんな感じです

• 本番の待機は time.sleep ではなく WebDriverWait を使う
• WebDriverWait は「条件が満たされるまで待つ」賢い待機
• 条件は expected_conditions で指定する
• よく使うのは presence / visibility / clickable / invisibility あたり
• 足りない条件は lambda で自作できる
• 暗黙的な待機との併用は避ける

最初は presence_of_element_located と element_to_be_clickable の2つだけ覚えておけば、だいたい何とかなります

実際にPythonでスクレイピングを動かしてみたい方は、Pythonでnetkeibaをスクレイピングしてみた実例もどうぞ、待機処理が実戦でどう効いてくるかイメージしやすいと思います

あなたのSeleniumの自動化が、もっと安定して動くようになればうれしいです