よく使うツール

ここで紹介するのは、バイブコーディングを始めたあと、必要に応じて追加する補助ツールです。最初に使うコーディング支援AIをまだ選んでいない場合は、先に はじめの一歩 を見てください。

最初から追加する必要はありません。音声入力はOS標準機能から試し、自動整形が必要ならTypelessを検討します。資料をテキストにするならMarkItDown、ブラウザ確認を自動化するならPlaywrightというように、困りごとが出てから選びます。

候補を探すときは、企業の公式リポジトリか、メンテナンスが続いているかを見ます。GitHubのスター数や利用者数は品質を保証しないため、採用前にREADME、更新日、ライセンス、Issue、依存関係、セキュリティ上の注意点を確認します。

このページでは、作業を補助する目的と、導入前に確認したい条件をまとめます。

まず用途で選ぶ

補助ツールは、名前ではなく、やりたいことから選びます。

話した内容を作業メモにする

入口: まずOS標準の音声入力。自動整形が必要ならTypeless

確認: 個人情報や内部情報を話していないか。

PDFやスライドをAIに読ませる

入口: MarkItDown

確認: 扱ってよい資料か。図表やスキャンPDFを目視確認するか。

画面を実際に確かめる

入口: Playwright

確認: 何をクリックし、何を確認したら合格か。

開発の型を取り入れる

入口: Product Starter などのスターター

確認: README、更新日、ライセンス、依存関係、今の目的に合うか。

人に使ってもらう前の抜けを減らす

入口: アクセシビリティ検査

確認: 誰が情報を見つけ、読んで、参加できる必要があるか。

ツール名、料金、無料枠、仕様は変わります。ここで紹介しているものも、使う前に公式サイト、README、料金、プライバシー、ライセンスを確認してください。

Typeless

Typeless

Typelessは、音声入力した内容を自動で整えてくれるツールです。バイブコーディングでは、作りたいものや困っていることを最初から整った文章にしようとすると、言葉が出にくいことがあります。その場合は、まず話して材料を出せます。

まとまりを気にせず話した内容を、自動で文章に整えられることが特徴です。「えー」「あー」のようなフィラーを減らし、順番が前後した話も文章や箇条書きに整えるため、あとからAIに渡す下書きとして使いやすくなります。

音声入力は必須ではありません。まずはスマホやPCのOS標準音声入力を試せます。話した内容を文字にするだけでなく、AIに渡しやすい形へ整える必要が出たときに、Typelessを選択肢にします。

向いている場面は、たとえば次のようなときです。

• 作りたいアプリやページのアイデアを出す
• 困っていることを説明する
• 画面を見ながら直したい点を話す
• エラーが出るまでの流れを残す
• 作業後の振り返りを書く

Typelessの データ処理の説明 によると、音声と文字変換に必要な限定的な文脈は外部のクラウドで処理されます。話し始める前に、個人情報、勤務先の内部情報、外部へ送れない資料名が含まれていないか確認してください。

公式の導入手順 では、マイク権限とアクセシビリティ権限が必要と説明されています。許可する内容を読み、必要な範囲だけ有効にします。料金や無料枠は変わることがあるため、使い始める前に現在のプラン内容も確認します。

このリンクには紹介用のパラメータが含まれており、利用状況によって紹介者に報酬が発生する場合があります。Typelessの Affiliate Program でも報酬の仕組みが案内されています。紹介リンクを使わず、検索して公式サイトから開くこともできます。

使う前に確認すること:

• 公式サイトの料金や無料枠
• クラウドに送られる音声や限定的な文脈の扱い
• マイク権限とアクセシビリティ権限の範囲
• 話す内容に個人情報、勤務先の内部情報、公開してはいけない資料名が入っていないか

Typelessで整えたメモも、別のAIへ送る前に内容を読み返します。誤変換を直し、送ってはいけない情報を取り除いてから、AIに作業前の確認をさせます。

次のメモを読んで、今回の作業を始める前に確認してください。
作りたいもの、今回やること、まだやらないこと、不安なことに分けてください。
この段階では、まだファイル編集はしないでください。

MarkItDown

microsoft/markitdown

MarkItDownは、Microsoft公式のPython製ドキュメント変換ツールです。Python 3.10以上が必要で、PDF、PowerPoint、Word、ExcelなどをMarkdownに変換し、AIやテキスト分析で扱いやすくできます。ほかのPythonツールと依存関係がぶつからないように、仮想環境へ導入する方法が推奨されます。

Markdownに変換すると、長い資料から必要な部分を確認し、AIへ渡す範囲を絞りやすくなります。ただし、元資料のレイアウトを高精度に再現するためのツールではなく、元ファイルを目視する作業の代わりにはなりません。

MarkItDownは、現在のプロセスと同じファイルアクセス権で動きます。実行しているユーザーが読めるファイルにはアクセスできるため、処理対象を必要なフォルダに限定します。信頼できないファイルを直接処理しないでください。

変換しても元資料の意味が完全に再現されるわけではありません。表、図、スキャンPDF、画像内文字は抜けることがあるため、重要な資料では画像メモや目視確認も残します。

繰り返し使う場合は、PDFやPowerPointを読むときの変換手順と目視確認の条件を、AGENTS.md や CLAUDE.md に書いておくと再利用できます。

使う前に確認すること:

• Python 3.10以上を用意し、仮想環境への導入方法を公式READMEで確認する
• 実行プロセスに与えているファイルアクセス権を確認する
• 出所や内容を確認できないファイルを直接処理しない
• 変換結果だけで判断せず、重要な図表やスキャンPDFは目視でも確認する

ただし、MarkItDownだけで全部分かるわけではありません。画像として埋め込まれた図や、スキャンPDFの文字は、そのままでは十分に読めないことがあります。そこで、資料読み取りの流れは次のようにスキル化しておくと安定します。

1. MarkItDownでテキストを抽出する
2. 並行して、ページ画像や図のスクリーンショットを保存する
3. Markdown内のどの位置に、どの図が対応するかを紐付ける
4. 図の内容、画像内の文字、読み取れない部分を別メモとして保存する
5. 最後に、テキスト抽出結果と画像メモを合わせて要約する

Playwright

Playwright公式の導入手順

Playwrightは、Webブラウザを自動操作するためのツールです。Webアプリのテスト、画面確認、クリック操作、フォーム入力、スクリーンショット取得、スマホ幅での表示確認などに使えます。

Playwrightが未導入の環境では、AIに確認用プロンプトを渡すだけでは実行できません。Node.jsを用意し、Playwright本体と操作用ブラウザを導入してから実行します。まだ導入しない場合は、自分でブラウザを開き、同じ確認項目を手動で確かめます。

特に便利なのは、次のような場面です。

• 作ったサイトが実際に表示されるか確認する
• スマホ幅で文字やボタンが崩れていないか見る
• フォーム入力やページ遷移が動くか試す
• スクリーンショットを保存して、見た目の差分を確認する
• 人に使ってもらう前に、主要なリンクや導線を実ブラウザでチェックする

PlaywrightはChromium、Firefox、WebKitを扱えます。ユーザーが見るラベルやボタン名を使って要素を探せるため、AIにブラウザ確認を任せる場合も、実際の操作結果やスクリーンショットを記録できます。

使う前に確認すること:

• Node.js、Playwright本体、操作用ブラウザが導入されているか
• 確認したいページやURL
• 合格にする条件
• スクリーンショットやログをどこに残すか
• ログインや個人情報を含む画面を扱ってよいか

Playwrightで実際のブラウザ確認をしてください。
確認すること:
- デスクトップ幅でページが表示される
- スマホ幅で文字やボタンがはみ出さない
- 主要リンクをクリックできる
- スクリーンショットを保存する
- 失敗した場合は、推測ではなく実際のエラーと画面状態を報告する

Product Starter

jujunjun110/product-starter

Product Starterは、Claude Codeへの指示でプロダクトを作るためのスターターキットです。2026年7月10日に確認したREADMEでは、Next.js、Supabase、Prisma、shadcn/ui、Tailwind、Vitest、dependency-cruiser、Biomeなどが使われています。

構成は更新されるため、利用時には現在のREADMEを確認します。

これは第三者が公開している高度なスターターで、Claude Code専用です。初心者の最初の一歩には使いません。小さな実践を1回通し、依存関係や外部サービスの確認が必要になってから検討します。

使う前にREADME、最終更新日、依存関係、ライセンスを確認し、今の目的に採用する部分と採用しない部分をAIに整理させます。

使う前に確認すること:

• 公式READMEと最終更新日
• ライセンス
• 前提になる技術や依存関係
• 自分の目的に必要な部分と、真似しない部分
• セキュリティや利用範囲に応じた確認の仕組みがあるか

目的と構成が合う場合は、開発の型をまとめて導入できます。

• フォルダ構成を一から考えなくてよい
• DDD 4層のような設計ルールを最初から持てる
• よくある作業をスキルやコマンドとして呼び出せる
• テストや依存方向のチェックを、品質ゲートとして使える
• pnpm verify のような確認コマンドをAIに実行させやすい

ただし、用意されている構成を理解しないまま採用すると、不要な依存関係や外部サービスまで増えることがあります。採用する部分と採用しない部分を分け、初期化前に確認します。

jujunjun110/product-starter の README と関連ファイルを読んでください。
/init-pj はまだ実行しないでください。

実行前に、次の項目を一覧にしてください:
- 作成・変更されるファイル
- 追加・更新される依存関係
- 必要になるアカウントや外部サービス
- 外部へ送信される可能性がある情報
- 料金が発生する可能性がある操作

採用する部分と採用しない部分も分けてください。
私が承認するまで、/init-pj、インストール、初期化、アカウント作成、外部送信を実行しないでください。

情報アクセシビリティの検査サブエージェント

Nagi-Inaba/information-accessibility-skill

これは、情報アクセシビリティのレビューや設計に使うためのCodex / Claude Code向けスキルとエージェントです。Webサイト、アプリ、文書、スライド、動画、イベント案内、会議運営、コミュニティ導線などを、「必要な人が情報を見つけられるか、受け取れるか、理解できるか、参加できるか、後から確認できるか」という観点で確認できます。

これを使う理由は、アクセシビリティのチェックリストを一から作らなくてよくなるからです。

使う前に確認すること:

• CodexやClaude Codeにスキル/サブエージェントを入れているか

• 入れていない場合は、下の通常AI向けプロンプトを使う

• レビュー対象に個人情報や内部資料が入っていないか

• 指摘をどのページや作業記録に残すか

• WebやアプリのUIレビューに使える

• PDF、スライド、告知画像の共有前チェックに使える

• イベントや会議の案内、字幕、文字起こし、資料共有の確認に使える

• CodexとClaude Codeの両方に入れやすい形で置いておける

• レビュー結果を、優先度、影響を受ける人、修正案、確認方法に分けて出せる

バイブコーディングでは、機能を作ることに意識が寄りがちです。しかし、実際に使う人が情報にたどり着けない、読めない、操作できない、後から確認できない状態は、利用しにくさや情報格差につながります。

このスキルを使うと、人に使ってもらう前の確認観点を揃えやすくなります。導入済みであれば、短い指示からレビューを始められます。

専用のスキルやサブエージェントを導入していない場合は、利用中のAIに次のように頼めます。

このページを、情報アクセシビリティの観点でレビューしてください。
Find / Receive / Understand / Participate / Continue の5つに分けて見てください。

確認してほしいこと:
- 初心者が必要な情報を見つけられるか
- 文字、画面、スマホ、読み上げで受け取りにくい情報がないか
- 誤解しそうな表現や長すぎる説明がないか
- 困ったときに相談しやすいか
- 後から作業を再開しやすいか

問題点、影響を受ける人、直し方、確認方法を表で出してください。

CodexやClaude Codeにサブエージェントを入れている場合は、もっと短く頼めます。

アクセシビリティのサブエージェントで検査して。