Claude Code を触りはじめた人が、わりと早い段階でぶつかる場面があります。

毎回、おなじ前置きを打ち直している。

「このプロジェクトは Python で、テストは pytest で、変更したら差分を要約して、危なそうなところを指摘して」……こういう文章を、朝も昼も夜も、そのつど打っている。長くなるとコピペ用のメモ帳に貼っておいて、そこから貼り付けている。

正直に言うと、僕もしばらくそうしていました。

でも、これは テキストファイルを1つ置くだけで、まるごと省略できます 。

置いたあとは、こう打つだけになります。

/summarize-changes

これだけで、さっきの長い前置きをぜんぶ渡したのと同じことが起きる。しかも、そのとき手元にある未コミットの差分まで自動で一緒に渡ってくれる。

この記事では、その「自分専用の /コマンド 」を 1つだけ 作ります。全機能の紹介はしません。1つ作って、実際に打って、返ってくるところまで。だいたい10分です。

この記事のゴールと、前提の話

ゴール

この記事を読み終えたとき、こうなっている状態を目指します。

練習用のフォルダに、スキルのファイルを 1つ置けている
Claude Code で /summarize-changes と打つと、自分の変更の要約が返ってくる
「じゃあ自分のあの作業も、これにできるな」と1つ思いつけている

「理解した」ではなく「動いた」まで持っていきたい、という感じです。

前提

Claude Code がすでにインストールされていて、ターミナルで claude と打つと起動する状態
Git が使えること（git --version で何か表示されればOK）

まだ Claude Code を入れていない場合は、公式の Quickstart が最短です。この記事はその次のステップにあたります。

用語を、先にかみ砕いておきます

途中で出てくる言葉を、はじめに整理しておきます。ここで身構える必要はまったくないので、ざっと眺めるくらいで大丈夫です。

言葉	意味
ターミナル	黒い画面に文字を打ってパソコンを操作する道具。Mac なら「ターミナル.app」、Windows なら「PowerShell」など
CLI	ターミナルで文字を打って操作する方式のこと。Claude Code はこの方式
リポジトリ	Git で変更履歴を管理しているフォルダのこと。ざっくり「プロジェクトのフォルダ」
スキル（Skill）	Claude に渡す「手順書」を書いたファイル。この記事の主役
frontmatter	ファイルの先頭に `---` で挟んで書く設定欄。「このファイルは何なのか」を書く場所
YAML	frontmatter で使われる書き方。`名前: 値` を並べるだけの、素直な形式

実行環境（この記事を書いたときの環境）

以下は実際に手元で動かして確認しています。

Claude Code 2.1.224（claude --version で確認）
macOS 14.8.3
Node.js v22.23.1
実行日: 2026年8月10日

バージョンが違うと表示が少し変わることはあります。ただ、この記事で扱う範囲は基本的な部分だけなので、大きくは変わらないかなと思います。

スキルって、要するに「手順書を1枚渡す」だけなんです

一言でいうと

スキルとは、Claude に覚えておいてほしい手順を書いた、ただのテキストファイルです。

公式ドキュメントには、こう書かれています。

Skills extend what Claude can do. Create a SKILL.md file with instructions, and Claude adds it to its toolkit.
（スキルは Claude にできることを広げます。手順を書いた SKILL.md ファイルを作ると、Claude はそれを自分の道具箱に加えます）
— Extend Claude with skills

道具箱、という表現がしっくりきます。プログラムを書くわけでも、何かをインストールするわけでもない。Markdown（見出しや箇条書きが書ける、あの記法）で手順を書いて、決まった場所に置く。それだけ。

「カスタムスラッシュコマンド」を探していた人へ

ここは大事なところなので、先に書いておきます。

ネット上の解説を読んでいると、「カスタムスラッシュコマンドは .claude/commands/ にファイルを置いて作る」という説明をよく見かけると思います。それ自体は今も間違いではありません。ただ、公式ドキュメントの現在の記述は、こうなっています。

Custom commands have been merged into skills. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way. Your existing .claude/commands/ files keep working.
（カスタムコマンドはスキルに統合されました。 .claude/commands/deploy.md にあるファイルと、.claude/skills/deploy/SKILL.md にあるスキルは、どちらも /deploy を作り、同じように動きます。既存の .claude/commands/ のファイルはそのまま動き続けます）

つまり、「カスタムスラッシュコマンドの作り方」と「スキルの作り方」は、いま同じもの なんです。既存の .claude/commands/ が壊れるわけではないので、すでに使っている人はそのままで大丈夫。これから作る人は、公式が推奨しているスキル形式（.claude/skills/<名前>/SKILL.md）で始めるのがよさそうです。

この記事では、スキル形式で作ります。

CLAUDE.md とは、役割が違います

Claude Code には CLAUDE.md という別のファイルもあって、ここで混乱しがちです。ざっくり分けると、こう。

	CLAUDE.md	スキル（SKILL.md）
中身	プロジェクトの事実（構成、規約、使っているツール）	やってほしい手順（調べて、まとめて、指摘して）
いつ読まれる	セッション中ずっと	そのスキルを使うときだけ
呼び方	呼ばなくても効いている	`/名前` で呼ぶ、または Claude が判断して使う

公式にも、判断基準が書かれています。

Create a skill when you keep pasting the same instructions, checklist, or multi-step procedure into chat, or when a section of CLAUDE.md has grown into a procedure rather than a fact.
（同じ指示・チェックリスト・複数ステップの手順を繰り返し貼り付けているとき、あるいは CLAUDE.md のある一節が「事実」ではなく「手順」に育ってきたときに、スキルを作りましょう）

僕の中での目安は、「同じ指示を3回打ったら、それはスキルにする」 です。3回打っているなら、4回目も打ちます。ほぼ確実に。

10分でやってみる — 自分の変更を要約してくれる `/summarize-changes` を作る

ここから手を動かします。

いきなり本番のプロジェクトで試すと、うまくいかなかったときに気持ちがしんどいので、練習用のフォルダを作って、そこで完結させます 。終わったらフォルダごと消せば、何も残りません。

Step 0. 練習用のフォルダを作る

ターミナルを開いて、次を打ちます。

mkdir -p ~/skill-practice
cd ~/skill-practice

1行ずつ、意味はこうです。

mkdir -p ~/skill-practice … ホームフォルダの下に skill-practice というフォルダを作ります。-p は「途中のフォルダがなかったらまとめて作る／すでにあってもエラーにしない」というおまじない
cd ~/skill-practice … いま作ったフォルダの中に移動します（cd = change directory）

Step 1. 練習用のリポジトリにする

スキルの中で「未コミットの差分」を使うので、Git の管理下にしておきます。

git init
printf 'def add(a, b):\n    return a + b\n' > calc.py
git add -A
git commit -m "init"

git init … このフォルダを Git の管理下にします
printf ... > calc.py … 足し算をするだけの短い Python ファイルを作ります
git add -A と git commit -m "init" … いまの状態を「1回目の記録」として保存します

もし git commit で名前とメールを聞かれたら、案内どおりに git config で設定してから、もう一度 git commit を打てば進めます。

続けて、わざと未コミットの変更を作ります 。これがスキルの材料になります。

printf 'def add(a, b):\n    return a + b\n\ndef div(a, b):\n    return a / b\n' > calc.py

割り算の関数 div を追加しました。ゼロで割ったときの処理は、わざと書いていません（あとで Claude に指摘してもらうためです）。

git status --short と打って、M calc.py のように表示されれば、変更が記録待ちの状態になっています。

Step 2. スキルを置くフォルダを作る

mkdir -p .claude/skills/summarize-changes

.claude/skills/ の下に、スキル1つにつきフォルダ1つ を作ります。ここで作った summarize-changes というフォルダ名が、そのまま /summarize-changes というコマンド名になります。ここ、あとでもう一度触れます。

先頭がドットで始まるフォルダは、Finder やファイル一覧では隠れて見えないことがあります。見えなくても、ちゃんとそこにあります。

Step 3. SKILL.md を書く

いよいよ本体です。次をそのまま貼り付けて、Enter を押してください。

cat > .claude/skills/summarize-changes/SKILL.md <<'EOF'
---
description: 未コミットの変更を要約し、気になる点を指摘します。変更内容を聞かれたときに使います。
---

## 今の変更内容

!`git diff HEAD`

## 手順

上の差分を2〜3個の箇条書きで要約し、そのあとに気になる点（エラー処理の不足、ハードコードされた値、更新が必要なテストなど）を挙げてください。差分が空なら「未コミットの変更はありません」と答えてください。
EOF

cat > ファイル名 <<'EOF' ... EOF は、「EOF と書いた行までの内容を、そのままファイルに書き込む」という書き方です。エディタを開かずにファイルを作れるので、記事の手順としては再現しやすいかなと。もちろん、VS Code などの好きなエディタで同じ内容を書いて保存しても、まったく同じです。

中身を、上から見ていきます。

--- で挟まれた部分が frontmatter 。ここに description を1行書いています
## 今の変更内容 以下が、Claude に渡される本文
!`git diff HEAD` は、あとで詳しく説明しますが、この場所に git diff HEAD の実行結果が差し込まれる という意味

Step 4. 打ってみる

Claude Code を起動します。

claude

起動したら、そのまま入力欄に打ちます。

/summarize-changes

/ を押した時点で、候補の一覧に summarize-changes が並んでいるはずです。自分が作ったコマンドが、メニューに載っている。 ここ、地味なんですが、ちょっと嬉しい瞬間だと思います。

Step 5. 返ってきたもの

僕の手元（Claude Code 2.1.224 / macOS 14.8.3、2026年8月10日実行）では、こう返ってきました。

## 変更内容の要約

- div(a, b) 関数を追加 — 2つの数値の除算を行う新しい関数を実装
- 既存コードに追加 — add() 関数の後に新しく追加

## 気になる点

1. ゼロ除算のエラー処理がない — b が 0 の場合、ZeroDivisionError が発生します。
   エラーハンドリングまたは入力検証が必要です
2. テストが作成されていない — 新しい関数のテストがあれば確認しましょう
3. ドキュメント/型ヒントがない — 関数の説明や引数の型情報があると保守性が向上します

ここで注目したいのは、「calc.py を見て」とも「差分を出して」とも言っていない ことです。/summarize-changes としか打っていない。

なのに、手元の差分をちゃんと読んで、ゼロ除算まで拾ってきている。

これが、手順書を1枚渡すということなんです。

いま何が起きたのか — 3つの部品に分けて見てみる

動いたところで、中身を分解します。ここを押さえると、次からは自分で好きなスキルを作れるようになります。

部品1: フォルダ名が、そのままコマンド名になる

.claude/skills/summarize-changes/SKILL.md を置いたら /summarize-changes になりました。これは偶然ではなく、公式にそう決まっています。

置いた場所	コマンド名
`.claude/skills/deploy-staging/SKILL.md`	`/deploy-staging`
`.claude/commands/deploy.md`	`/deploy`

ここで1つ、つまずきやすいポイントがあります。frontmatter には name という項目も書けるのですが、自分用・プロジェクト用のスキルでは、name はコマンド名を変えません 。公式には、name は「一覧に表示されるラベル」であり、コマンド名は「ディレクトリ名（またはファイル名）から決まる」と書かれています。

つまり、/deploy にしたければ、name: deploy と書くのではなく フォルダ名を deploy にする 。これが正解です。

部品2: `description` は、Claude が読む「使いどころの説明」

frontmatter の項目は実はたくさんあるのですが、公式が「推奨」としているのは description だけです。

---
description: 未コミットの変更を要約し、気になる点を指摘します。変更内容を聞かれたときに使います。
---

これは飾りではありません。Claude が「いま、このスキルを使うべきか」を判断するために読んでいます。

だから /summarize-changes と打たなくても、「いま何変えたっけ」と普通に聞いただけで、Claude が勝手にこのスキルを使ってくれることがあります。逆に、勝手に使われたくない場合の止め方もあって、それは次の章で扱います。

description を書くときのコツは、「何をするか」だけでなく「いつ使うか」も書く ことかなと思います。上の例でいうと、後半の「変更内容を聞かれたときに使います」の部分です。

部品3: !`コマンド` は、Claude に渡す前に実行される

ここが、この機能のいちばん面白いところです。

!`git diff HEAD`

この1行があると、何が起きるか。公式の説明はこうです。

The !`<command>` syntax runs shell commands before the skill content is sent to Claude. The command output replaces the placeholder, so Claude receives actual data, not the command itself.
（!`<command>` という書き方は、スキルの内容が Claude に送られる前にシェルコマンドを実行します。コマンドの出力がその場所を置き換えるので、Claude が受け取るのはコマンドそのものではなく、実際のデータです）

順番にすると、こうなります。

/summarize-changes と打つ
Claude が何かする前に 、git diff HEAD がシェルで実行される
その出力が、!`git diff HEAD` と書いてあった場所に、そのまま差し込まれる
差分が埋まった状態の手順書が、Claude に渡る

だから Claude は、ファイルを探しにいく手間なしに、最初から差分を持った状態で考え始められる。「Claude にコマンドを実行させている」のではなく、「Claude に渡す前に、こちらが材料を用意している」 という違いです。

複数行のコマンドを走らせたいときは、```! で始まるコードブロックが使えます。

## 環境
```!
node --version
npm --version
git status --short
```

ちなみに、! が効くのは 行の先頭か、空白の直後にあるときだけ です。次のように、他の文字の直後にくっつけて書いた場合、コマンドは実行されず、そのままの文字として残ります。

KEY=!`date`

どこに置くか — 「自分だけ用」と「プロジェクト用」

さっきは .claude/skills/ に置きました。これは「そのプロジェクトだけで使えるスキル」です。置き場所によって、使える範囲が変わります。

置き場所	パス	使える範囲
Personal（自分用）	`~/.claude/skills/<名前>/SKILL.md`	自分の全プロジェクト
Project（プロジェクト用）	`.claude/skills/<名前>/SKILL.md`	そのプロジェクトだけ
Plugin	`<plugin>/skills/<名前>/SKILL.md`	プラグインが有効な場所
Enterprise	管理設定で指定	組織の全ユーザー

同じ名前のスキルが複数の階層にあるときは、enterprise が personal を上書きし、personal が project を上書きします 。

使い分けは、こんな感じかなと思います。

自分のクセを覚えさせるもの → Personal（~/.claude/skills/）。「コミットメッセージはこの形式で」など、どのプロジェクトでも同じにしたいもの
そのプロジェクト固有の手順 → Project（.claude/skills/）。Git にコミットすれば、チーム全員が同じ /コマンド を使えるようになります

もう1つ、地味に嬉しい仕様があります。スキルのファイルを編集しても、Claude Code を再起動する必要がありません。 公式にはこう書かれています。

Claude Code watches skill directories for file changes. ... Claude Code picks up the change within the current session, without a restart.
（Claude Code はスキルのディレクトリの変更を監視しています。……セッション中に、再起動なしで変更を拾います）

書きながら試して、うまくいかなければ直して、もう一度打つ。このループが速いのは、育てていく上でけっこう効きます。

ただし、セッション開始時に存在しなかったスキルの親フォルダを新しく作った場合は、再起動が必要 です。今回のように .claude/skills/ を新規に作ってから始めたときは、その後に claude を起動すれば問題ありません。

2つ目のスキル — 引数を受け取れるようにする

1つ目が動いたら、次は「呼ぶときに何かを渡せる」スキルを作ってみます。ここまでできると、応用がぐっと広がります。

同じ練習用フォルダで、次を打ちます。

mkdir -p .claude/skills/explain-file
cat > .claude/skills/explain-file/SKILL.md <<'EOF'
---
description: 指定したファイルの中身を初心者向けに説明します。
argument-hint: [ファイル名]
disable-model-invocation: true
---

$ARGUMENTS というファイルを読んで、プログラミングを始めたばかりの人にもわかるように、3行で説明してください。
EOF

新しく出てきたものが3つあります。

`$ARGUMENTS` — 打ったときの引数が、ここに入る

/explain-file calc.py と打つと、$ARGUMENTS の場所が calc.py に置き換わります。それだけです。

引数が複数あるときは、$0 で1つ目、$1 で2つ目、というふうに位置で取り出せます。この記事では深追いしませんが、必要になったら公式の「Available string substitutions」の表を見るのがいちばん早いです。

`argument-hint` — 補完のときに出るヒント

argument-hint: [ファイル名]

/ を押してコマンドを選ぼうとしたとき、「ここに何を書けばいいか」を表示してくれます。3日後の自分のために書いておく欄、という感じかなと。

`disable-model-invocation: true` — 勝手に使わせない

さっき、「description を見て Claude が勝手にスキルを使うことがある」と書きました。それを止めるのがこれです。

disable-model-invocation: true

これを書くと、自分が /explain-file と打ったときだけ動きます 。公式にも、こういう使いどころが挙げられています。

Use this for workflows with side effects or that you want to control timing, like /commit, /deploy, or /send-slack-message. You don't want Claude deciding to deploy because your code looks ready.
（副作用のあるワークフローや、実行のタイミングを自分で決めたいものに使います。/commit、/deploy、/send-slack-message のようなものです。コードが仕上がって見えるからといって、Claude の判断でデプロイされては困りますよね）

デプロイ、コミット、通知の送信。このあたりは、迷わず付けておいたほうが安心だと思います。

動かしてみる

claude

/explain-file calc.py

僕の手元では、こう返ってきました。

このファイルは、数学の計算をするための簡単なプログラムです。
`add`という関数は2つの数を足し算して結果を返し、
`div`という関数は2つの数を割り算して結果を返します。
つまり、足し算と割り算を自動でしてくれるツールが入っているファイルということです。

3行で、と書いたとおりに3行で返ってきています。calc.py という引数がちゃんと渡っていることも確認できました。

`!` は、けっこう強力です

ここは、便利さの話ではなく 安全の話 です。短いですが、いちばん読んでほしい章かもしれません。

!`コマンド` は、Claude が「実行してもいいか」を考えて実行するものではありません。スキルの内容が Claude に渡る前に、無条件でシェルが走ります。

公式の言葉を借りると、こうです。

This is preprocessing, not something Claude executes. Claude only sees the final result.
（これは前処理であって、Claude が実行しているものではありません。Claude は最終結果だけを見ます）

自分で書いたコマンドなら、何が走るかわかっているので問題ありません。気をつけたいのは、他の人が書いた SKILL.md を持ってきて置くとき です。

僕が自分に課しているルールは、この3つです。

自分が書いたコマンドだけを ! に入れる 。少なくとも、中身を読んで理解できるものだけ
他所から持ってきた SKILL.md は、置く前にテキストとして開いて全部読む 。! の行があったら、そのコマンドが何をするか必ず確認する
組織や共有マシンで配る場合は、止められるようにしておく

3つ目について、公式には無効化の設定が用意されています。

{
  "disableSkillShellExecution": true
}

これを設定に書くと、各コマンドは実行されず [shell command execution disabled by policy] という文字列に置き換わります。ユーザー、プロジェクト、プラグイン、追加ディレクトリ由来のスキルが対象で、Claude Code に最初から入っているスキルには影響しません。

便利な機能ほど、こういう栓の位置を先に知っておいたほうが、安心して使えるかなと思います。

つまずきやすいところと、よくある質問

Q1. `/` を押しても、作ったスキルが出てきません

いちばん多いのがこれです。順に確認してみてください。

場所が合っているか … .claude/skills/名前/SKILL.md になっていますか。.claude/skill/（単数）や .claude/skills/SKILL.md（フォルダなし）だと読まれません
起動した場所が合っているか … プロジェクト用のスキルは、そのフォルダ（またはその配下）で claude を起動したときに読まれます。まったく別のフォルダで起動していないか確認してみてください
フォルダを新しく作った直後か … .claude/skills/ 自体をセッション開始後に作った場合は、claude を起動し直すと出てきます

Q2. `name: deploy` と書いたのに `/deploy` になりません

これは仕様どおりです。自分用・プロジェクト用のスキルでは、コマンド名は フォルダ名 から決まります。name は一覧に出る表示ラベルです。/deploy にしたいなら、フォルダ名を deploy にしてください。

Q3. `.claude/commands/` に置いているものは、書き直したほうがいいですか

いえ、そのままで動きます 。公式にも「既存の .claude/commands/ のファイルはそのまま動き続けます」と明記されています。急いで移す必要はありません。

新しく作るぶんはスキル形式にしておくと、後から補足ファイル（テンプレートや参考資料）を同じフォルダに足したくなったときに楽です。なお、同じ名前でスキルとコマンドの両方がある場合は、スキルのほうが優先されます 。

Q4. 呼んでいないのに、Claude が勝手にスキルを使ってきます

description を読んで「これは使うべきだ」と判断しているためです。意図しないなら、frontmatter に disable-model-invocation: true を足してください。そのスキルは、自分が /名前 と打ったときだけ動くようになります。

Q5. 逆に、`/` のメニューには出したくないけど、Claude には知っておいてほしい

user-invocable: false を書くと、/ のメニューから隠れて、Claude だけが使う状態になります。「この古いシステムはこういう仕組み」みたいな背景知識を持たせたいけれど、コマンドとして打つ意味はない、というときの使い方です。

Q6. SKILL.md はどれくらい長く書いていいですか

公式のヒントは 「500行以内に収める」 です。理由は、スキルが読み込まれると、その内容がその後の会話にずっと残り続けるから。つまり毎ターン、地味にコストがかかります。

長い参考資料は、同じフォルダに別ファイルとして置いて、SKILL.md からは「詳しくは reference.md を見て」と案内する形にすると、必要なときだけ読まれるようになります。

Q7. 手元で作ったスキルは、クラウド側でも使えますか

~/.claude/skills/ に置いた個人スキルは、Cowork やクラウドセッションからは読まれません。それらは claude.ai アカウント側で有効化したスキルを読みます。クラウドセッションでプロジェクトのスキルを使いたい場合は、.claude/skills/ をリポジトリにコミットしておけば読まれます。

逆に、スキルにしない方がいい作業もあります

便利だと、つい何でもスキルにしたくなります。ここは正直に、効かない場面も書いておきます。

僕がスキルにしないのは、この3つです。

1. 1回しかやらない作業

スキルを書く時間のほうが長くなります。3回打ったら作る、くらいでちょうどいいかなと。

2. 毎回こちらの判断が変わる作業

「このPRをレビューして」は良いスキルになりますが、「このPRをマージすべきか決めて」は向きません。判断基準がその都度変わるものを手順書に固定すると、書いた当時の判断に引きずられます。むしろ判断を鈍らせる方向に働くこともある。

3. CLAUDE.md に書くべき「事実」

「このプロジェクトは TypeScript で、テストは vitest」。これは手順ではなく事実なので、CLAUDE.md 側の仕事です。スキルにすると、呼ばないと効かない知識になってしまいます。

そしてもう1つ。スキルを増やしすぎると、自分がどれを作ったか思い出せなくなります 。/ を押して一覧を眺める時間が、そのまま手で打っていた時間を超えたら、たぶん作りすぎです。

最初は、1つか2つ。それで十分だと思います。

まとめ — 明日、何をスキルにするか

今日やったことを、もう一度並べます。

練習用フォルダを作って、Git リポジトリにした
.claude/skills/summarize-changes/SKILL.md を1つ置いた
/summarize-changes と打ったら、自分の変更の要約が返ってきた
argument-hint と $ARGUMENTS で、引数を渡せるスキルも作った
! の危なさと、その止め方を知った

覚えることは、実はこれだけです。

フォルダ名 = コマンド名
description は「何を」だけでなく「いつ使うか」も書く
!`コマンド` は、Claude に渡す前に走る

最後に、1つだけ宿題のようなものを。

この1週間で、AI に3回以上打った指示を、思い出してみてください。

たぶん1つはあるはずです。「テストを走らせて失敗だけ要約して」でも、「このファイルの依存関係を図で説明して」でも。それを .claude/skills/ にファイル1枚置くだけで、明日から / ひとつになります。

練習用フォルダは、rm -rf ~/skill-practice で消せます。試したあとは、消してしまって大丈夫です。

参考リンク（この記事を書く前に読んだ公式ドキュメント / 2026年8月10日に確認）

Extend Claude with skills — Claude Code Docs … 本記事の主な出典。スキルの作り方、置き場所、frontmatter、! による動的な文脈注入、カスタムコマンドとの統合について
Claude Code Quickstart … インストールと最初の起動
Claude Code Docs 全体
Agent Skills（オープン標準） … Claude Code のスキルが準拠している標準

本文中の日本語訳は、原文の意味を保つ範囲での筆者による意訳です。仕様は更新されることがあるので、細かい挙動は必ず上記の公式ページで確認してください。

このシリーズの他の記事

AIエージェントを、1記事につき1つずつ動かしていくシリーズです。

生成AI活用エンジニア&3児のパパ。AI×開発の実践知を毎日発信しています。Xでも発信中です → https://x.com/akira_papa_AI