見出し画像

AIアシスタンスの第一歩：ブラウザ活用ワークフロー

koふみ

まずは難しいセットアップを捨てましょう。
ChatGPT／Claude／Geminiの“チャットだけ”で、今日から開発は加速します。
この一歩が、あなたのAIDD（AI駆動開発）を本気で動かし始めます。


この記事で目指すゴール

本記事は、ブラウザベースのAIチャット（ChatGPT／Claude／Gemini） を使って、エンジニアの開発ワークフローに“最小コストで”AIを組み込む方法を、実例と運用のコツ付きでまとめます。セットアップは不要、コピー＆ペーストだけで十分な価値 を引き出す――ここが「AIアシスタンスの第一歩」です。最後に、限界と次の一手（IDE連携へ進む道）も整理します。

なぜ“まずはブラウザ”なのか

  • ゼロセットアップ：アカウント登録だけで即スタート。OS依存のツール導入や権限設定がいりません。

  • 直感的UI：自然言語のチャットにコード・ログ・仕様を貼るだけ。習熟コストが低い。

  • 汎用性：テキスト生成からコード補助、デバッグ支援、要件のブレストまで“幅広くそこそこ強い”。

  • 最初の地図：AIが“どの領域で効くのか”を見極める踏み台として最適。

すでに多くの開発者がブラウザAIを仕事・学習・実験に活用し始めており、導入のハードルが限りなく低い入り口 として機能しています。

まずは触ってみる：最小の“成功体験”を作る

ここから、実際のやり取りの例 を通して、どのように“最短で価値”を引き出すかを見ていきます。全てブラウザ上のチャットだけで完結します。

例1：JavaScriptのワードカウント関数を生成させる

お題：「文字列を受け取り、単語数を返す関数を作って」

ポイント

  • LLMは正規表現での分割・トリム・空文字対応 まで含めた“実用的な実装”を提示できます。

  • 提案コードはそのままコピペして、ブラウザのDevToolsコンソール で即検証できます。実例では、複数スペースや空文字、1語だけのケースも正しく数え上げました。

/**
 * 与えられた文字列の“単語数”を返す関数（例）
 * - 連続スペースや改行を1区切りとして扱う
 * - 空文字や空白のみの入力は0を返す
 */
export function countWords(input) {
  // 前後の空白を除去して空かどうかを先に確認
  const s = String(input).trim();
  if (!s) return 0;

  // 1つ以上の空白（スペース/改行/タブ）で分割
  const words = s.split(/\s+/);
  return words.length;
}

コツ：出力された関数は “なぜこの実装にしたのか” を質問すると、LLMは根拠（空文字が0になる理由、 \s+ 採用理由など）を説明してくれます。 説明を引き出す ことで信頼性を検証できます。

例2：テストも一緒に作る（VTEST／Vitest相当）

お題：「さきほどの関数に対するVTESTの単体テストを書いて」

ポイント

  • シンプルな文／複数スペース／空文字／単一語／改行／タブ など、エッジケースを網羅 したテストを自動生成。

  • StackBlitzのようなオンライン環境に貼り付けて その場でテスト実行 し、パスを確認できます。

// countWords.test.ts（例）
// VTEST(Vitest)での基本テストケースを想定
import { describe, it, expect } from "vitest";
import { countWords } from "./countWords";

describe("countWords", () => {
  it("単純な文を数える", () => {
    expect(countWords("hello world")).toBe(2);
  });
  it("複数スペースを許容する", () => {
    expect(countWords("foo   bar   baz")).toBe(3);
  });
  it("空文字は0", () => {
    expect(countWords("   ")).toBe(0);
  });
  it("単一の単語は1", () => {
    expect(countWords("token")).toBe(1);
  });
  it("改行やタブも区切りとする", () => {
    expect(countWords("a\nb\tc")).toBe(3);
  });
});

学び：LLMは“テストの骨子”をつくるのが得意。境界値と異常系 も指示しておくと網羅度が上がります。

例3：デバッグ相談で“思い込み”を崩す

ケース：forEach 内の async/await が原因で、外側の try/catch が“想定通りに効かない”。
AIの診断：forEach は await を待たないため、 例外が外側に伝播しない ／ 逐次実行を望むなら for...of 、並列なら Promise.all が選択肢――という 原因と改善案 を提示。

// 例：並列実行＋個別エラー把握の雛形（説明目的の擬似コード）
const results = await Promise.all(
  urls.map(async (u) => {
    const res = await fetch(u);
    if (!res.ok) throw new Error(`status=${res.status}`);
    return res.json();
  })
);
// まとめてtry/catchする or 個別に捕捉する設計に

学び：エラーパターンの “なぜ起きるか”を言語化 してもらうと、原因特定後の対策（逐次／並列）を ユースケースに応じて選べる ようになります。

例4：よそのコード／古い自分のコードを“解説してもらう”

  • OSS（例：Vueコアのref.ts）のような 馴染みのないコード も、役割・責務・主要API・概念 を要約して把握可能。

  • 個人の小規模ライブラリ のコードでも、目的やデータフロー、主要関数の働きを 段階的に説明 できます。 “読む前に全体像” が手に入るのは大きな時短。

例5：要件定義のたたき台を“ブレスト”する

お題：「オンライン英語講師と生徒をつなぐプラットフォーム。考慮点と技術案をブレストして」

  • ユーザーロール／スケジューリング／ライブ授業・予約／学習ツール（宿題・チャット・AIチューター） などの 機能観点 を抽出。

  • フロント／バックエンド／ビデオ／決済／通知 までの 技術スタック候補 を一括提示。企画初期の“見落とし防止リスト”として有効。

ほかにも：ブラウザAIで“すぐ効く”ユースケース集

  • 依存関係のメジャーアップグレード対応：移行ガイドを貼って変更点の抽出→影響箇所のあたり付け。

  • React→Vue／Angularなどのコンポーネント変換：構造の差分を解説させつつ段階変換。

  • ユーザーストーリー／受け入れ基準の起草：プロダクト要件をBehaviorに落とす“叩き台”。

  • コードスメルの指摘と改善提案：命名／責務分割／関数長／ネスト深度などの初期診断。

  • カスタム正規表現の作成：例と非例を提示して“安全なパターン”を出力。

  • 読みやすさのためのリファクタ：コメント方針／関数抽出／型付けの方向性まで。

結論：LLMは“現実のコード”で学習しており、機能的かつテスト可能 な出力が得やすい。入門としてのブラウザAI は、幅広い用途で“費用対効果が高い”のが持ち味です。

ブラウザAIの“限界”と、付き合い方

限界1：IDEとの“往復作業”がつらい

  • コード／ログを 手動で貼る 必要があり、文脈（コンテキスト）が欠落 しやすい。

  • 相談量が増えると コピー＆ペーストの摩擦 が無視できなくなる。

限界2：プロジェクト全体へのアクセスがない

  • 関連ファイルや構成を 自律的に読み込めない ため、前提を毎回伝えるコスト がある。

  • コンテキストウィンドウ（AIが一度に読めるトークンの上限）があるため、長文を投げ込めば良いわけではない。

だからこそ：まずブラウザAIで 何が効くか を掴み、次の段階（IDE連携など）に進むと、コンテキスト管理や差分適用が自動化され、摩擦が劇的に減ります。本稿は“第一歩”にフォーカスしますが、次の一歩 があることは覚えておいてください。

すぐ使える“プロンプトの型”

型A：実装生成（小さく具体）

目的: 文字列の単語数を返す関数
制約: JS/TS, 連続スペース/改行/タブを区切り, 空文字は0
入出力例: "hello world" -> 2, "  " -> 0, "a\nb\tc" -> 3
評価: 可読性/テスト容易性、O( n )
出力: 関数本体 + 実装理由の説明 + 改良案(任意)

型B：テスト生成（境界重視）

対象: countWords()
前提: 仕様/制約を箇条書き
ケース: 単純文, 連続空白, 空文字, 単語1, 改行/タブ, Unicode混在
出力: VTEST(Vitest)のテストコード + 各ケースの意図説明

型C：デバッグ（症状→原因→修正）

症状: try/catchが効かない
状況: forEach内でasync/await, 例外が外に出ない
要望: 原因を平易に説明 → 逐次/並列の2案 (for...of / Promise.all)
出力: それぞれのコード例 + トレードオフ

型D：コード解説（鳥瞰→要素）

対象: [貼り付けコード]
要望: 役割/責務/主要API/データフロー/副作用/前提技術の整理
出力: 図解イメージのテキスト化 + 読解の優先順 + 変更時の注意点

型E：要件ブレスト（観点の漏れ防止）

目的: ESLプラットフォームの機能一覧と技術候補
観点: ロール, スケジューリング, ライブ授業, 予約, 学習ツール, AI補助
技術: フロント/バックエンド/ビデオ/決済/通知
出力: 必須/任意の分類 + MVPの最小スコープ案

ポイント：Doneの定義・制約・例・評価を冒頭に入れるだけで、出力のブレは大幅に減ります。

1週間で慣れるミニ計画（ブラウザAIだけでOK）

Day 1-2：単発タスクで“速さ”を体験

  • 小さな関数生成・正規表現・翻訳・README整形など。

  • プロンプト型A/B を使いまわし、成功体験 を刻む。

Day 3-4：デバッグと解説で“理解”を深める

  • ログ＋再現手順＋対象コードを投げ、“原因→修正案×2”で回答させる。

  • OSSや他人のコードを 鳥瞰→要素 で説明させる（型D）。

Day 5-6：要件ブレストとテスト先行

  • 新機能アイデアを 観点リスト化 し、MVPの最小 を切り出す（型E）。

  • テストの雛形から 実装を逆算 する流れを試す（型B→A）。

Day 7：ふりかえりとテンプレ整備

  • 成功/失敗プロンプトをテンプレ化し、再現性 を上げる。

  • “ブラウザAIで十分／足りない”の境界を言語化し、次の一歩（IDE連携）を検討。

品質と安全のための運用ヒント

  • 根拠を必ず聞く：「なぜその実装？」→説明と代替案を出させる。

  • 小さく検証：DevTools・StackBlitzで すぐ動かす。

  • 仕様を先に固める：Done・制約・例・評価観点を プロンプトの最初に。

  • コピー前提で整える：出力コードに コメント／型／命名方針を要求。

  • 守秘とライセンスに注意：機微情報は伏せ字／匿名化。出力は 自分で最終確認。

これらはすべて、ブラウザAIだけでも実践可能な“基本の型”です。

ブラウザから先へ：次の一歩の見取り図

本稿の範囲は レベル1（ブラウザチャット） ですが、IDE連携（レベル2以降） に進むと、

  • プロジェクトの文脈（ファイル/エラー/履歴） を自動で読み、

  • 選択範囲だけ編集／ファイル横断の差分提案 ができ、

  • 監督付きエージェント で複数ファイルを一気に触れる――といった 摩擦の少ないワークフロー に到達します。まずは “ブラウザだけで勝つ” を積み重ね、その先へ。

まとめ

  • ブラウザAIは最小コストの“入口”。セットアップ不要で、実装生成・テスト・デバッグ・解説・要件ブレストまで“幅広くそこそこ強い”。

  • プロンプトの型（目的／制約／例／評価）を整えるだけで、出力の再現性と品質 が跳ね上がる。

  • 限界（コピー＆ペースト摩擦、プロジェクト文脈の欠落、コンテキスト上限）はあるが、第一歩として絶大。適切な習熟の後に IDE連携 へ進めば、さらに加速する。

知識は武器とかけまして、レゴブロックと解く、その心は？
知識のひとつひとつは小さなレゴブロック
でも、組み合わせれば世界を変えるアイディアをカタチにする武器になる！

またKnowledge Oasisでお会いしましょう
案内人はkoふみでした

いいなと思ったら応援しよう！