大きく近道する考え方

ここは、基本を一通り読んだあとに、既存の道具や開発の型を取り入れるためのページです。公式ドキュメントや公開されている実装をAIと読み、今の目的に必要な部分だけを使います。

このページは、基本の流れを試した後に読む発展編です。はじめて読む人は、先に「はじめの一歩」「場面別の頼み方」「フォルダ構成」「戻し方」を読んでください。

既存の道具から始める

作りたいものに近い例や、すでに検証されている手順があれば、最初から作り直す必要はありません。

誰かが作っているものを参考にする
既存の公開スキルやエージェントを使う
オープンソースのツールを使う
企業が公式に出しているドキュメントをAIに読ませる
繰り返す作業はスクリプトにして保管する

公開されているコード、スキル、開発補助ツールを探す場所の1つがGitHubです。最初はブラウザで検索できます。慣れてきたら GitHub CLI を導入し、CodexやClaude Codeから gh コマンドを使う方法もあります。

GitHub CLIを使えるようにしておくと、たとえば次のことができます。

gh repo clone でGitHub上のリポジトリを簡単に手元へ持ってくる
gh search repos で、条件に合うリポジトリをAIに探させる
GitHub連携プラグインやMCPと組み合わせて、AIに調査、比較、候補抽出を任せる

ただし、GitHubにログインするときは、必要以上に広い権限を与えないようにします。仕事用や顧客用の非公開リポジトリをAIに読ませる前には、対象範囲と実行するコマンドを必ず確認してください。

候補を探す方法の1つは、「直近1か月に作成され、現在のスター数が多いリポジトリを探して」とAIに頼むことです。ただし、現在のスター数は品質を保証しません。

検索結果は候補を見つける入口として扱います。採用する前に、README、最終更新日、ライセンス、Issueの状況、依存関係、セキュリティ上の注意点を確認します。

GitHubで、直近1か月に作成され、現在のスター数が多いAI開発系リポジトリを探してください。
対象は、今やりたい作業に使えそうなスキル、エージェント、ブラウザ自動化、資料処理、開発補助ツールです。

スター数は参考情報として扱ってください。
企業公式リポジトリやメンテナンスが続いているものを優先しつつ、README、最終更新日、ライセンス、Issue、依存関係、セキュリティ上の注意点も同じ重さで見てください。
各候補について、何に使えるか、初心者が真似できる部分、採用前に確認することを短く整理してください。

コマンドで探すなら、たとえば次のような形です。

$since = (Get-Date).AddMonths(-1).ToString("yyyy-MM-dd")
gh search repos "AI agent created:>$since" --sort stars --order desc --limit 20

目的は、流行を追いかけることではありません。今の目的に直接関係しない調査や初期設定を減らし、判断と確認に時間を使うことです。

自分の見方をAIに伝える

AIに状況を正確に伝えるには、自分が何を見て、どこに違和感を持ち、何を優先しているかを言葉にします。これはAIに人間と同じ考え方を求めるのではなく、判断に必要な観点を共有する作業です。

たとえば、自分が見ている画面、気になっている違和感、完成形として想像している雰囲気を、ただ「いい感じにして」と言うだけでは、AIは別の角度から対象を捉えてしまいます。

「いい感じ」の中身を、次の観点に分けて伝えます。

どこを見ているのか
何を同じ対象だと捉えているのか
何を違和感だと感じているのか
どの観点を優先しているのか
どこから先はまだ判断しなくてよいのか

この目線を共有すると、AIが別の前提で修正を進める可能性を下げられます。

今から伝える内容は、一般論として広げず、私がいま見ている対象を同じ目線で捉えるための前提として読んでください。

私が見ている対象:
-

違和感を持っている点:
-

優先したい観点:
-

まだ判断しなくてよいこと:
-

この目線を保ったまま、次に何を直すべきかを整理してください。

いきなりコードを書かせない

エンジニアではない人が、いきなり「バイブコーディングでこういうサイトを作って」と頼むと、AIはその場でコードを書き始めることがあります。

AIはいろいろな開発手法を知っています。ただし、その場で常に最適な進め方を選んでくれるとは限りません。

いきなり作り始めると、次の問題が起きやすくなります。

思い描いていた完成形と違うものができる
少しずつ進める中で、進捗管理がしにくくなる
メンテナンスしにくいコードになる

これを避けるには、目的と検証方法を含む開発手順を先に決めます。

TDD: 先に期待する動きやテストを書いてから作る
ドキュメント駆動開発: 先に仕様、使い方、判断基準を書いてから作る
PRD/要件メモ: 作るもの、やること、やらないこと、完成条件を決める
レビュー駆動: 作ったあとに、差分、テスト、リスクを見てもらう

手法の名前が分からない場合は、AIに候補と選ぶ理由を出してもらいます。

いきなりコードを書き始めないでください。
まず、目的と検証方法を含む進め方を決めてください。

次の順番でお願いします。
1. 目的と完成条件を整理する
2. 今回やること、やらないことを分ける
3. 既存の類似ツールや実装例を探す
4. TDD、ドキュメント駆動開発、通常の小さな実装のどれで進めるべきか提案する
5. 最初の小さな作業単位だけ決める

この段階では、まだファイル編集をしないでください。

AIが考える余地を減らす

AIには考えさせるべきところと、考えさせない方がよいところがあります。

毎回すべてのデータをAIに読ませて一つずつ判断させると、必要以上に利用量が増えることがあります。AIの判断がずれた場合は、その後の出力にも影響します。

機械的にできる部分は、なるべくスクリプトにします。

ファイル一覧を作る
PDFやスライドから文字を抽出する
画像だけをページごとに切り出す
JSONやCSVを検査する
リンク切れを確認する
テストやビルドを実行する
変更されたファイルだけを一覧化する

スクリプトやコマンドで処理できる部分は、再利用可能な形で保管します。AIには、その処理を実行させ、出力結果を次の判断材料に使わせます。

グローバルルールとしては、次のように書いておくと扱いやすいです。

機械的に判定できる作業は、なるべくAIの推論で処理しないでください。
既存スクリプト、テスト、lint、grep、JSONパース、ハッシュ確認、ブラウザ検証など、決定的な方法を優先してください。
同じ処理を繰り返す場合は、再利用できるスクリプトやチェックリストとして保存してください。

公式ドキュメントを吸収する

AIを開発している企業の公式ドキュメントには、利用方法、制約、推奨される確認手順がまとめられています。

特に AnthropicのPrompting best practices や、context engineeringの記事は、AIに何を渡すか、どのように作業状態を保つかを考える上で参考になります。

ただし、自分で全部読む必要はありません。

次の公式ドキュメントを読んで、私のCodexまたはClaude Code環境で使えるルールに変換してください。

やってほしいこと:
- 重要な原則を10個以内に圧縮する
- AGENTS.md または CLAUDE.md に入れるべきルールに変換する
- 毎回使えるチェックリストにする
- すでに自分の環境にあるルールと重複するものは統合する
- 実行コマンドや検証方法がある場合は、具体的に残す

Google Cloudが発表している Open Knowledge Format も、この方向性に合っています。OKFは、MarkdownにYAMLフロントマターを付け、人間とAIエージェントが同じ知識を読めるようにする考え方として参考になります。仕様やサンプルは GoogleCloudPlatform/knowledge-catalog の okf ディレクトリにあります。

このような外部の形式は、仕様やサンプルが変わることがあります。自分の作業ルールとして固定する前に、公式READMEやSPEC、更新日を確認し、今の目的に必要な部分だけ取り入れます。

これも、自分で細かい書式を覚える必要はありません。

このメモを、OKFの考え方に近い形でMarkdown化してください。
YAMLフロントマターには、title、description、tags、resource、timestampを入れてください。
本文は、人間が読んでも分かる説明と、AIが次回参照しやすいチェックリストに分けてください。

よく使うツール

ツール紹介は独立ページに分けました。資料読み取り、ブラウザ確認、開発の型、アクセシビリティ検査など、実際に使う道具をまとめて見たいときは次のページを開いてください。

よく使うツールを見る