develop-ai-functions-example

develop-ai-functions-example スキルの概要

develop-ai-functions-example は何のためのスキルか

develop-ai-functions-example スキルは、vercel/ai リポジトリ内の examples/ai-functions/src/ にある実行可能なサンプルを新規作成・修正するための、用途を絞ったビルドガイドです。一般的なプロンプト作成支援ではありません。AI SDK の関数デモ、provider の検証、テストに近い fixture という、このリポジトリ特有の慣例に沿ったサンプルを作れるようにするのが役割です。

このスキルを使うべき人

次のような場合は develop-ai-functions-example スキルが向いています。

• AI SDK 関数用の新しいサンプルを追加したい
• 既存サンプルを別の provider 向けに調整したい
• ある provider が機能をサポートしているか検証したい
• 既存の examples ツリー配下に最小の再現例や fixture を作りたい
• 独自パターンを持ち込まず、repo の構造に合わせて進めたい

一方で、generateText() が抽象的にどう動くかを LLM に聞きたいだけなら、このスキルは少し用途が狭すぎるはずです。

実際に解決してくれる仕事

多くのユーザーが欲しいのは説明文ではありません。正しいフォルダに、正しい形で、正しい SDK 関数を使った、リポジトリ固有のミスが少ない動くサンプルです。develop-ai-functions-example は、AI Functions の examples 領域に特化した repo-aware な実装アシスタントと考えるのがいちばん実態に近いです。

汎用的なコーディングプロンプトと何が違うか

一般的なプロンプトでもサンプルコードの下書きはできますが、この repo における分類やファイル配置のロジックを外しがちです。develop-ai-functions-example では、たとえば次のような実務的な前提が加わります。

• examples/ai-functions/src/ 配下にすでにあるサンプル分類
• 機能タイプと配置先ディレクトリの対応関係
• このリポジトリで examples が担う役割: 検証、デモ、fixture
• 広いチュートリアルよりも、最小で実行可能なサンプルを優先する姿勢

向いている範囲

develop-ai-functions-example for Skill Examples が特に力を発揮するのは、次のカテゴリでの作業です。

• generate-text/
• stream-text/
• generate-object/
• stream-object/
• agent/
• embed/
• embed-many/
• generate-image/
• generate-speech/
• transcribe/
• rerank/
• middleware/

この範囲指定は重要です。develop-ai-functions-example は、この repo のレイアウト内でサンプルを作ることに最適化されており、アプリ設計や SDK API surface、プロダクション向けアーキテクチャ設計のためのスキルではありません。

develop-ai-functions-example スキルの使い方

インストール文脈と適用先

develop-ai-functions-example install のガイダンスは、vercel/ai リポジトリ内で使う場合、またはその examples 構造を自分の環境で踏襲したい場合に有効です。よくあるセットアップは次のとおりです。

npx skills add vercel/ai --skill develop-ai-functions-example

そのうえで、examples/ai-functions/src/ 配下のサンプルファイルを新規作成・編集・検証するタスクに限って、このスキルを呼び出します。

まずは正しいサンプルカテゴリを選ぶ

コードを依頼する前に、対象となる関数ファミリーを決めてください。ここが最も効果の大きい判断ポイントで、フォルダ配置とサンプルの形の両方がここで決まります。

例:

• 通常の単発テキスト出力 → generate-text/
• トークンやチャンクのストリーミング → stream-text/
• schema 制約付きの構造化出力 → generate-object/
• 構造化出力のストリーミング → stream-object/
• 単一入力に対する embeddings → embed/
• バッチ入力に対する embeddings → embed-many/
• ツール利用を含む複数ステップのワークフロー → agent/

この判断を省くと、生成されるサンプルが API レベルでそもそも間違っている可能性があります。

スキルに渡すべき入力情報

develop-ai-functions-example usage の品質は、依頼内容の具体性に強く左右されます。最低でも次の情報は入れるのがおすすめです。

• 対象の関数。たとえば generateObject() や streamText()
• provider と model。わかっていれば明記
• そのサンプルが検証用なのか、docs 風のデモなのか、テスト fixture なのか
• 想定する入力と出力
• streaming、tools、schema validation、middleware が必要かどうか
• 依存関係、ファイル名、環境変数に関する制約

弱い入力例:

• “Make an AI example.”

より良い入力例:

• “Create a minimal generateObject() example under examples/ai-functions/src/generate-object/ that tests structured extraction from product review text using a Zod schema and a provider supported in this repo.”

ざっくりした目的をスキル向けプロンプトに落とし込む

良い develop-ai-functions-example guide 用プロンプトは、成果物、配置先ディレクトリ、使う関数、そして何を検証したいのかを明示します。

使いやすい型は次のとおりです。

• 何を作りたいか
• どこに置くべきか
• どの AI SDK 関数を使うべきか
• どの程度まで provider 前提を置いてよいか
• どれだけ最小構成にするか、あるいは production 寄りにするか
• 成功条件をどう定義するか

プロンプト例:

“Use develop-ai-functions-example to create a minimal example in examples/ai-functions/src/stream-text/ showing streamText() with a provider already used in the repo. Keep it short, runnable, and clearly focused on streaming output rather than app integration. Include any required env vars and explain why this belongs in stream-text/ instead of generate-text/.”

まず SKILL.md を読み、その後で近いサンプルを見る

このスキルで見えるサポートファイルは SKILL.md だけです。最初にこれを読むべきです。カテゴリの対応表と、この repo での意図がまとまっているからです。その後、修正予定の配置先ディレクトリにある近いサンプルを確認してください。repo 全体の広いドキュメントを読むよりも、ローカルの命名規則や実装パターンを早くつかめます。

実用的な読む順番:

1. skills/develop-ai-functions-example/SKILL.md
2. 対象フォルダの examples/ai-functions/src/
3. 意図している機能に最も近い sibling example を 1〜2 個
4. 近くで使われている provider 固有の import や env パターン

サンプルの目的に合わせる

このリポジトリでは、examples は単なるドキュメント用途だけではありません。develop-ai-functions-example に出すプロンプトでも、次のどれを最適化対象にするのかを明示してください。

• provider サポートの検証
• 機能デモ
• 再現可能な fixture
• 試行錯誤のための実験

これが重要な理由:

• 検証用サンプルは最小かつ明示的であるべき
• デモ用サンプルは API の要点が見えるべき
• fixture は不要なバリエーションを避けるべき
• 実験用は多少粗くてもよいが、正しいフォルダ配置は必要

出力は最小構成だが実行可能に保つ

良い develop-ai-functions-example skill の出力は、多くをやるものより、やることを絞ったものです。依頼時には次を求めると安定します。

• 明確な関数呼び出しを 1 つ
• 必要最小限の import のみ
• 意図がわかりやすい入力
• 小さくシンプルな出力処理
• 必要な env 変数の明示
• そのフォルダで前提になっていない限り framework の scaffolding は入れない

こうしておくと、モデルがアプリコードを足しすぎて、本来見せたい SDK の挙動が埋もれる失敗を減らせます。

明示するとよいリポジトリパス

repo に沿った出力を得たいなら、リクエスト内でパスを直接書くのが有効です。特に次のパスは有用です。

• examples/ai-functions/src/generate-text/
• examples/ai-functions/src/stream-text/
• examples/ai-functions/src/generate-object/
• examples/ai-functions/src/stream-object/
• examples/ai-functions/src/agent/
• examples/ai-functions/src/embed/
• examples/ai-functions/src/embed-many/

パスを直接指定すると、develop-ai-functions-example が中立的なサンプルを勝手に作るのではなく、そのディレクトリに合うパターンを選びやすくなります。

新しいサンプルを作る実践ワークフロー

再現性の高い進め方は次のとおりです。

1. 対象の関数ファミリーを特定する
2. そのフォルダの sibling example を確認する
3. フォルダ、関数、provider、目的を含めてスキルに依頼する
4. 最初のサンプルを生成する
5. 検証やデモに不要なものを削る
6. 想定している provider で実行する
7. 近くのファイルに合わせて命名、入力、env 処理を調整する

最初から何も指定せずに完成形を求めて、その後で repo に合わせて後付け修正するより、たいていはこちらのほうが速く進みます。

通常のプロンプトではなくこれを使うべき場面

主なリスクが repo との不一致、つまりフォルダ違い、AI SDK 関数の選択ミス、複雑さの過不足、examples ツリーに合わないデモになってしまうことなら、develop-ai-functions-example usage を使う価値があります。examples/ai-functions/src/ の外側で、より広いアーキテクチャ支援が必要なら、通常のプロンプトのほうが適しています。

develop-ai-functions-example スキル FAQ

develop-ai-functions-example は vercel/ai repo 専用か

最も価値が高いのは vercel/ai 内です。examples/ai-functions/src/ のサンプル分類に根ざしたスキルだからです。自分の examples repo でパターンとして流用することもできますが、この構造に合わせる重要性が低いなら、効果も下がります。

このスキルは初心者向けか

はい。少なくとも「何をデモしたいか」が決まっているなら使いやすいです。目的を適切なサンプルカテゴリに対応づけてくれるので、判断の幅を狭められます。逆に、text generation、structured generation、embeddings、agents、middleware のどれにすべきか自体がまだ決まっていない段階では、初心者向けとは言いにくいです。

単なるコーディング依頼より優れている点は何か

最大の利点は repo への適合性です。develop-ai-functions-example は、構造化出力のサンプルを plain text 用フォルダに置いてしまう、streaming デモなのに非 streaming API を使ってしまう、fixture に無関係なアプリコードを盛り込みすぎる、といったミスを避けやすくします。

develop-ai-functions-example を使わないほうがよいのはいつか

次のようなものが必要なら使わないでください。

• プロダクション向けアプリのアーキテクチャ
• UI 統合のガイダンス
• 汎用的な AI SDK チュートリアル
• repo 横断のリファクタリング方針
• サンプル作成を超える評価・ベンチマーク戦略

このスキルは意図的に守備範囲を狭くしています。

provider は最初から正確に決めておく必要があるか

必須ではありませんが、指定したほうが出力品質は上がります。わからない場合は、近いサンプルですでに使われている provider を使うよう依頼すると、生成されるファイルを既存パターンに照らして検証しやすくなります。

新規作成だけでなく既存サンプルの修正にも使えるか

使えます。特に、SDK 関数を切り替えたい、provider を差し替えたい、再現例をもっと小さくしたい、ファイルを正しいカテゴリに合わせて整えたい、といったケースで有効です。

develop-ai-functions-example スキルを改善する方法

具体的なリポジトリ上の配置先を指定する

develop-ai-functions-example を改善するうえで最も効くのは、正確な配置先フォルダと関数を明示することです。たとえば次を比べてみてください。

弱い例:

• “Add an example for object extraction.”

強い例:

• “Use develop-ai-functions-example to add a minimal generateObject() example under examples/ai-functions/src/generate-object/ that extracts invoice fields from plain text and prints validated JSON.”

後者は API の選択とファイル配置の曖昧さを取り除けます。

出力の目的を最初に書く

ユーザーが最も気にするのは、そのサンプルがサポート可否の確認用なのか、使い方を教えるためのものなのか、fixture として使うものなのかです。これをプロンプトの最初の一文で明示してください。この判断だけで、コードの形がかなり変わることがあります。

初稿での過剰実装を防ぐ

よくある失敗は、余計なラッパー、アプリの scaffolding、複数の関心事が混ざった返答になることです。次を明示的に指定すると防ぎやすくなります。

• 最小コード
• 役割は 1 つ
• UI なし
• framework のセットアップなし
• コメントは必要最小限のみ

こうすると、examples ツリーに沿ったサンプルになりやすく、ミニアプリ化を防げます。

ローカルの実装パターンに合わせるよう頼む

develop-ai-functions-example skill の結果を良くしたいなら、近くのサンプルに合わせて命名、import、env 処理をそろえるようモデルに伝えてください。この一言は、“best practices” を求めるより効くことが少なくありません。

例:

• “Match the style of sibling files in examples/ai-functions/src/stream-text/ and avoid introducing a new pattern unless required.”

入力と期待する出力形を具体的にする

もう一つの典型的な失敗は、デモロジックが曖昧なままになることです。サンプル入力と期待する出力を明示すると、検証しやすいサンプルになります。

より良いプロンプト詳細:

• 入力テキストや payload
• 期待するレスポンスの形式
• 出力を stream するのか、log に出すのか、schema-validate するのか
• 何を成功条件とみなすか

広げるより絞る方向で反復する

最初のドラフトの後は、機能追加ではなく曖昧さの除去で改善するのが効果的です。

• “some provider” を具体的な provider に置き換える
• “an object” を schema に置き換える
• “example script” を対象ディレクトリに置き換える
• “works” をテスト可能な出力期待に置き換える

develop-ai-functions-example の改善では、たいてい機能を増やすよりスコープを狭めるほうがうまくいきます。

受け入れる前にカテゴリ適合を確認する

結果を採用する前に、次を確認してください。

• 使っている関数に対して正しいフォルダか
• 検証用として十分に最小か
• 1 つの中核挙動を明確に示しているか
• maintainer が見て「ここに置く理由」がわかるか

もし違うなら、コードを先に直すより、まずプロンプトを修正したほうが早いことが多いです。

provider と環境前提を明示してプロンプトを改善する

サンプルが認証情報や provider 固有挙動に依存するなら、それを直接書いてください。そうしないと、技術的にはもっともらしくても、repo 内で実行しづらいコードが出てくることがあります。

追加すると有効な情報:

• 必要な env var 名
• provider SDK に関する前提
• 安定性が重要なら model 名
• fallback を許容するかどうか

sibling example を受け入れ基準にする

出力品質を上げる実践的な方法として、生成ファイルを一般的なコード標準ではなく、近くのサンプルと比べて判断してください。もし sibling example より明らかに複雑、焦点がぼやけている、構造が違いすぎると感じたら、ローカルのパターンに合わせて書き直すよう依頼するのが有効です。