Diaを使った効率的な公式ドキュメント調査術

Diaって何？

DiaはThe Browser Companyが開発しているAIブラウザです。Arcブラウザの後継として作られていて、「AIファースト」なブラウジング体験を目指してます。

普通のブラウザとの一番の違いは、ブラウジング中にAIと対話しながらウェブページを理解できるってところ。特に技術ドキュメント読むときにこれが結構効いてきます。

実際どう使えるのか？API仕様調査の例

具体例で説明した方が分かりやすいと思うので、実際に使ってみた時の話をします。

ケース：Google Ads APIのキャンペーン情報取得仕様を確認したい

Google Ads APIで広告キャンペーンの情報を取得したいとき、Google Ads Query Language（GAQL）の書き方とか、レスポンスの構造とか確認する必要がありますよね。公式ドキュメント開いて…ってやるわけですが。

従来のやり方だと

• 公式ドキュメントを開く
• サイドバーからCampaign Serviceを探す
• ページをスクロールしてGAQLの構文例を読む
• 「あれ、このフィールドってSELECT可能だっけ？」ってなって別ページに飛ぶ
• レスポンスの構造を確認するために別のセクションに飛ぶ…
• 属性と指標とセグメントの違いがよくわからなくて読み直す…

みたいな感じで、情報が散らばってて結構行ったり来たりするんですよね。Google Ads APIって特にドキュメントが膨大なので余計に大変です。

Diaを使うと

Google Ads APIのドキュメントページを開いた状態で、Diaに話しかけられます。

自分：「キャンペーンの名前とステータスを取得したいんだけど、GAQLでどう書けばいい？」

Dia：「このページの例に沿うなら、次のGAQLでキャンペーンの名前とステータスを取得できます。
SELECT campaign.name, campaign.status FROM campaign ORDER BY campaign.id
並び順は任意ですが、よく使われるのはID順です。必要に応じて条件も追加できます…」

ドキュメントのどこに書いてあるかわからなくても、すぐに具体的なクエリ例が手に入ります。これだけでも便利なんですが、さらに突っ込んで聞けるのがポイントです。

自分：「このクエリをAPIに投げたら、レスポンスはどんな構造で返ってくる？GoogleAdsRowって何？」

Dia：「Search/SearchStreamはGoogleAdsRowの配列を返し、各行に選択フィールドが入ります。1つのGoogleAdsRowは、あなたのGAQLのSELECTで指定した各リソース（今回ならcampaign）を1行として表現し、その行の中に選択した属性・指標・セグメントがフィールドとして格納されます…」

つまり、「こういうリクエスト投げたらこういうレスポンス返ってくる」っていうイメージを、ドキュメントを行ったり来たりせずに対話で掴めるんです。

さらに深掘りもできる

実装を進めていくと、「インプレッション数も取りたいな」みたいに要件が増えていきますよね。

自分：「キャンペーン情報に加えてインプレッション数も取得したい場合、クエリはどう変わる？」

Dia：「インプレッション数は指標フィールドなので、SELECTにmetrics.impressionsを追加します。
SELECT campaign.name, campaign.status, metrics.impressions FROM campaign
期間を絞る場合はセグメントを併用します…」

この調子で、実装しながら「次はこれどうするんだっけ？」を対話で解決していけます。

エラーケースの確認も楽

API実装してると、エラーハンドリングの確認も必須ですよね。

自分：「存在しないフィールドをSELECTしたらどんなエラーが返る？」

Dia：「GAQLの検証で失敗し、『無効な/選択不可なフィールド』等の詳細付きエラーが返ります。典型的には『そのフィールドはselectableではない』『FROMで指定したリソースでは使用不可』といった理由がメッセージに含まれます…」

エラーハンドリングの仕様も、わざわざエラーコード一覧のページに飛ばなくても確認できます。実装中に「あれ、これってどうなるんだっけ？」ってなった時のフリクションが減るのが地味に効きます。

概念の理解もスムーズ

Google Ads APIって、「属性」「セグメント」「指標」みたいな概念が出てきて、最初は混乱しますよね。

自分：「属性とセグメントと指標の違いって何？使い分け方は？」

Dia：「属性はリソースの性質、セグメントは切り口、指標は数値実績です。属性はキャンペーンや広告グループそのものの情報（campaign.id、campaign.nameなど）。セグメントはデータをどの切り口で分割するか（segments.date、segments.deviceなど）。指標は実績の数値（metrics.impressions、metrics.clicksなど）です…」

こういう「概念の違い」って、ドキュメント読んでるだけだと意外と掴みづらいんですよね。対話で確認できると理解が早いです。

他にも便利だったポイント

メソッドの使い分けも教えてくれる

「AとBどっち使えばいいの？」みたいな質問ができるのも便利でした。

自分：「SearchとSearchStreamの違いって何？どういう時に使い分ける？」

Dia：「Searchはページング、SearchStreamはストリーミングで行が順次届きます。Searchは1回の呼び出しでページ単位の結果を返し、エラー時のリトライや再開が簡単です。SearchStreamは大量データのレポーティングやETLで高速に取り込みたいときに向いています…」

実装方針を決めるときに、こういう「どっちを使うべきか」の判断材料がすぐ手に入るのは助かります。

英語ドキュメントの壁が下がる

英語読めないわけじゃないけど、日本語に比べたらやっぱり時間かかるじゃないですか。特に複雑な仕様の説明とか。

Diaだと、日本語で質問したら日本語で答えてくれるので、英語ドキュメント読むときの心理的ハードルが下がります。ブラウザの翻訳機能使うのとは違って、文脈理解した上で説明してくれるので分かりやすいです。

ページ内のどこに書いてあるか教えてくれる

AIに聞いて満足して終わり、じゃなくて、「詳しくはこのページの○○を参照してください」みたいに元の記載場所も教えてくれるので、ちゃんと一次情報も確認できます。今回の例でも、Campaign リファレンスやクエリ文法のページへのリンクを示してくれました。

使ってみて感じたメリット

調査の時間が体感で半分くらいになった

特に初めて触るAPIの仕様確認とかは、従来だと30分くらいかかってたのが15分くらいで済むようになった感じです。ドキュメント読んで→試して→また読んで、みたいなループが減るのが大きいですね。

「とりあえず読む」が「必要な情報だけ取る」に変わる

今までって、ドキュメント全体をざっと読んで全体像掴んでから細部見る、みたいな読み方してたんですけど、Diaだと「今知りたいことだけピンポイントで聞く」ができるようになりました。

もちろん全体を理解する必要がある場合もあるんですけど、「とりあえず動かしたい」みたいな時は効率が全然違います。

理解の確認ができる

ドキュメント読んで「たぶんこうだろう」って思ってても、実は違ったりすることありますよね。Diaに「つまりこういうこと？」って確認できるのは地味に助かります。

自分：「つまり、指標を使う場合は必ずセグメントも指定しないといけないってこと？」

Dia：「いえ、必須ではありません。指標だけでも取得できますが、その場合は全期間の集計値になります。日付などで分割したい場合にセグメントを使います…」

みたいな感じで、自分の解釈が合ってるか確認しながら進められます。

注意点というか、こういう使い方がいいと思ったこと

AIの回答を鵜呑みにしない

当たり前ですけど、AIなので間違うこともあります。特に最新の仕様変更とか、マイナーなエッジケースとかは間違ってることもありました。

なので、AIの回答をヒントにして、最終的にはちゃんと公式ドキュメントの記載を確認するっていう使い方がいいと思います。幸いDiaは参照元のページも示してくれるので、そこから確認しやすいです。「理解の補助」くらいの位置づけで。

質問は具体的に

「このAPIについて教えて」みたいな漠然とした質問より、「このフィールドを取得するにはどう書けばいい？」みたいに具体的に聞いた方が、欲しい回答が返ってきやすいです。

コード例を求める

「具体的なコード例を見せて」って言うと、使い方のイメージが掴みやすいです。ドキュメントのサンプルコードより、自分の状況に合わせたコード例を出してくれたりするので。

どういう人に向いてるか

• 英語ドキュメント読むのに時間がかかる人
• 新しいAPI触る機会が多い人
• 「とりあえず動かしたい」を優先したい人
• ドキュメント読んでても理解が曖昧になりがちな人
• 複雑なAPIの概念理解に苦労する人

逆に、「ドキュメントは最初から最後まで全部読む派」「AIツール使うのに抵抗ある」みたいな人には合わないかもしれません。

まとめ

Diaを使うことで、ドキュメント調査が「読む作業」から「対話して理解する作業」に変わりました。特にAPI仕様の確認みたいな、「この場合どうなる？」っていう細かい確認が必要な場面では結構効率が上がります。

完璧なツールではないので、使いどころは選ぶ必要がありますが、開発効率を上げたいエンジニアは試してみる価値あると思います。

今後さらに機能が追加されていくと思うので期待してます。