product-ops

プロダクトとロードマップの管理

Airtable でプロダクト運用のワークフロー（ロードマップ、顧客フィードバック、ローンチ、OKR、スプリント、リリース）を設定して運用し、チームの規模、サブワークフローの優先度、顧客の特性に合わせて調整します。構築に着手する前に対象範囲を確認してください。同じきっかけでも、3 テーブルの個人用ワークスペースを意味する場合もあれば、複数のベースにまたがるエンタープライズポートフォリオを意味する場合もあります。適切なスキーマは、ユーザーが実際に何を調整しようとしているかによって異なります。

対象ユーザーと解決しようとしている課題

製品の形態は、ユーザー像と課題がそれぞれ異なる次の3つに分類できます。

• ソフトウェア製品チーム — 一見すると当然の対象に見えますが、実際のケースの半数未満です。 PM、PMM、エンジニアリングリード、デザイナー、創業者／1人でPMを務める人。 主な優先事項：経営陣やGTM向けのロードマップの可視化、需要シグナルを伴うフィードバックと機能の連携、OKRの展開、ローンチの調整、キャパシティとコミットメントの明確化。典型的な課題：Productboard／Jira／Smartsheet／スプレッドシート／スライド資料にまたがるツールの乱立 — 「ツール間を行き来する作業」、「信頼できる情報源が多すぎる」、「PMがデータの検索やコピーに週2～3時間費やしている」、「PMの時間の40％が社内からのロードマップに関する質問への回答に費やされている」、フィードバックが_「ブラックホールに消えてしまう」_。
• テクノロジー以外の業界の製品チーム。 アパレル／ファッション／消費財のプロダクトマネージャー（PLM型 — ライン計画、BOM、技術パック、サンプル追跡）、銀行／フィンテック／資本市場（規制対象で段階審査型）、製薬／バイオテクノロジー／医療機器（コンプライアンス重視）、メディア／ゲーム（リリース頻度とフランチャイズのポートフォリオ）、航空宇宙／自動車（APQPとサプライヤーとの連携）。 主な優先事項：段階的なコンプライアンスを伴う製品ライフサイクル管理、同期されたベースを介したベンダー／パートナーとの調整、BOMとSKUのガバナンス、イニシアチブのROI／IRR／NPVに基づくビジネスケース審査、規制対応の監査証跡の集約。典型的な課題：_「手つかずのまま」_の古いPLM／SoRシステム、バージョンの衝突を招くExcelの乱立、専門ツールと経営層の審査をつなぐ「翻訳レイヤー」の必要性、現行ツールでは徹底できない規制上の監査証跡要件。
• 大規模組織の複数チームにまたがるプロダクトオペレーション。 プロダクトオペレーションリード、プロダクトオペレーションディレクター、大規模な製品組織のPMOディレクター、プロダクト担当VP。 主な優先事項：各チームを横断したポートフォリオの集約、カットラインのシナリオを含むキャパシティ制約下での計画、チーム横断の依存関係の追跡、数百のイニシアチブにわたるOKRの整合、モバイル対応の経営層向けダッシュボード。典型的な課題：「週末を費やす報告作業」、戦略的意図と実務の間で生じるポートフォリオのずれ、「プロダクト／エンジニアリング以外ではJiraの理解度が限られている」、「経営層向けのJiraデータの手作業による変換」。

3つすべてに共通する、より広範な課題：

• ツールの乱立と、信頼できる唯一の情報源の崩壊。 1つのベースで、PMツール、エンジニアリング用トラッカー、スプレッドシート、スライド資料、メールのスレッドなど、5つ以上のツールを置き換えることもよくあります。最初に必要なのは、ツールをもう1つ追加することではなく、統合することです。
• 手作業によるレポート作成の負担。 ステータス更新、経営層向け資料、週次サマリー、QBRの準備など、システムで生成できるレポートの作成に、PMの時間のかなりの部分が費やされています。これを自動化することが、通常、最も効果の大きい早期の成果につながります。
• フィードバックと機能の連携不足。 顧客の声はNPS、サポートチケット、Slack、営業メモ、アプリ内の情報、通話の文字起こしなど、さまざまなチャネルから届きますが、ロードマップの意思決定とのつながりが追跡できません。生のシグナルから需要を加味した優先順位付けまでを結ぶ構造化されたリンクがなければ、フィードバックは_「ブラックホールに消えてしまいます」_。
• 部門横断の引き継ぎでの情報欠落。 明確な担当、依存関係、共通スキーマがないと、デザイン → エンジニアリング → マーケティング → CSの引き継ぎで情報の正確さが失われます。
• 理想と実運用におけるAIのギャップ。 ほとんどの顧客は、プロダクトオペレーションでAIを本番運用する段階にはなく、まだ試験導入中です。ワークフローは、AIが利用可能な場合にはスムーズに組み込める一方、AIがなくても機能する必要があります。

言葉遣いや優先順位付けを調整する際に、この情報を活用してください。小規模チームの創業者が重視するのは、軽量なバックログとフィードバックと機能の連携です。テクノロジー以外の業界のPMが重視するのは、ライフサイクル、コンプライアンス、ベンダーとの調整です。プロダクトオペレーションリードが重視するのは、ポートフォリオの集約とキャパシティのシナリオです。同じスキルでも、導入のきっかけは異なります。

スキャフォールディングの前に：対象範囲を確認する

プロダクトオペレーションは、ソフトウェア、銀行、アパレル、製薬、メディア、航空宇宙、エネルギーなど、幅広い業界にまたがります。「当然」とされがちなテック系プロダクトチームの前提が当てはまるのは、実際のケースの半分にも満たないのです。まずは対象範囲について3つ質問し、回答に応じて掘り下げます。一度にすべてを聞こうとせず、チームの規模とサブワークフローから始め、3つ目の質問は回答が重要な場合に尋ねてください。

1. チームの規模と構成。 1人／小規模（10人未満）／中規模（10〜50人）／大規模（50人以上）／エンタープライズ（複数チーム／複数拠点）。スキーマ形状のデフォルトを決めます。5人のチームと200人のプロダクト組織では、望ましいスキャフォールディングは異なります。
2. 最初に取り組むサブワークフロー。 「ロードマップ、顧客フィードバック、ローンチ調整、OKR、スプリント計画、その他のどれですか？」 どのWorkモードのプレイブックを読み込むかが決まります。ほとんどのユーザーが最初に必要とするのは、すべてではなく、このうちの1つです。
3. 顧客／ユーザーの構成。 「プロダクトに関する意思決定では、名前の分かる顧客やアカウント（B2B）を追跡しますか、それとも幅広いユーザー層のシグナルを集計しますか（コンシューマー）。あるいは、その両方ですか（混合／B2B2C）？」 スキーマにARRで重み付けした集計を行うAccountsテーブルが必要か、ボリュームで重み付けしたシグナルを扱うCohorts／Segmentsテーブルが必要か、あるいは両方が必要かを判断します。抽象的なビジネスモデルの分類ではなく、実際にどのようなデータを追跡しているかという運用面から尋ねてください。

関連する場合に限り、必要に応じて次の項目も確認します。

• 既存のエンジニアリングトラッカーはありますか？（Jira／Linear／Azure DevOps／なし。）多くのプロダクトオペレーションのセットアップはJiraと連携します。同期計画に影響するほか、「翻訳レイヤー」という位置付けが適している場合もあります（経営幹部やGTM向けに、AirtableをJiraの人に分かりやすい表層として使う形です）。
• 単一用途のPMツールから移行しますか？（Productboard／Aha／Cycle／Monday／Smartsheet／Notion／Miro。）よくあるパターンであり、例外ではないため、移行プレイブックが必要かどうかを確認します。
• 社外向けのインターフェースが必要ですか？（顧客ポータル、外部向けロードマップビューアー、ブランド付きフィードバックページ。）カスタムアプリの構築レイヤーが必要になる可能性があります（詳しくは下の「出力」を参照）。
• AIの承認済みベンダーに関する制約はありますか？（Geminiのみ、サードパーティ製LLMは不可など。）エンタープライズではよくあるパターンで、スキルが推奨できるAI連携に影響します。

最初の3つの質問と、必要に応じた追加質問を行えば、通常は1回の対話でスキャフォールディングの内容が明確になります。話を聞く前にフレームワークを押し付けないでください。

2つのモード

セットアップモード：基盤をスキャフォールディングする

ユーザーが 「ロードマップ用のベースを設定して」 ／ 「Airtableでプロダクトオペレーションを構築して」 ／ 「機能リクエストを追跡して」 と依頼した場合は、対象範囲を確認した後、MCP経由でスキーマをスキャフォールディングします。手順は次のとおりです。

1. 対象範囲を確認する（上記を参照）— 回答を読み取ります。ユーザーがいきなり 「とにかく作って」 と言った場合でも、省略してはいけません。5分間の対象範囲の確認は、形の合わないものを作り直すよりも効率的です。
2. チームの規模と顧客の構成に合ったスキーマ形状を選ぶ。 スキル本文にインラインで記載された主要な形状は5つあり、ニッチな形状も2つ用意されています。
3. MCP経由でスキーマを構築する — ベース、型付きフィールド、リンクされたレコード、数式、ロールアップ、サンプルデータ／初期データを作成します。スキーマは他のすべての土台となるため、エージェントの労力を、より豊富な型付きフィールド、名前が分かりやすく色も工夫されたステータス用のsingleSelect、ロールアップ件数を使ったリンクレコードの関係性にかけてください。
4. UIの設定を引き継ぐ — ビュー、インターフェース、自動化、フォーム、きめ細かな権限設定、同期ウィザードなど、AirtableのUIで行うほうがよい設定を引き継ぎます。引き継ぎの形式については、下の「構築計画の出力」を参照してください。
5. ユーザーがブランド付きUI、社外向けポータル、埋め込み型インターフェース、またはデータを操作するチャットボットを希望する場合は、カスタムアプリのレイヤーを構築する。 これは任意です。references/build-shapes.mdを参照してください。

主要なスキーマ構成

最も一般的な5つの構成で、呼び出しの大半をカバーします。それぞれ、B2B／コンシューマー／混在型のバリエーション（Accounts テーブルと Cohorts テーブル、ARR 加重とボリューム加重の優先順位付け、Salesforce 同期とアプリストアからのデータ取り込み）に対応します。フィールドごとの詳細は references/schema-shapes.md をご覧ください。

• 軽量なバックログ（1テーブル） — 長文テキストの Notes フィールドでインラインのメモを記録する Backlog テーブルを作成し、スレッド形式のディスカッションには Airtable のネイティブなレコードコメントを使用します。エンタープライズ向け PM ツールは重すぎると感じ、Airtable から「移行するつもりがない」小規模なエンジニアリングチーム向けです。使われないロードマップやフィードバックの構造を押し付けないでください。また、ネイティブコメントと長文テキストフィールドで用途を満たせる場合は、別個の Notes／Discussion テーブルを作成しないでください。
• 個人／小規模（3テーブル） — Roadmap（Now／Next／Later）、Customer feedback、Releases。細部を決めすぎずにプロダクトオペレーションを始めたいユーザー向けの標準的なスターター構成です。スコアリング（RICE）と、カウントのロールアップを使った基本的なフィードバックと機能の関連付けを追加します。
• 中規模（5〜6テーブル） — Sprints、Sprint tasks、OKRs を追加します。3段階の階層（OKR → Feature → Sprint task）は、Airtable の標準的な構造に合致します。ステークホルダー別のインターフェース（Leadership／PM／Engineering）を用意します。
• 大規模（標準的な7テーブル構成） — Team members、Customer accounts を追加します。Airtable のプロダクトオペレーション構成ガイドに準拠します。複数のプロダクトチームにまたがる組織レベルの集計には、ベース間同期を推奨します。
• エンタープライズ／SAFe 準拠 — チーム・四半期ごとの Capacity、Dependencies、PI staging、Cut-line scenarios を追加します。Initiatives に Capex／opex／ROI／IRR／NPV の事業計画フィールドを設けます。権限管理されたドリルダウンが可能な、複数四半期にわたるスイムレーンビューを用意します。

ニッチな構成は2種類あります。スコープに関する回答が該当を示す場合にのみ提示します。

• ステージゲート／フェーズゲート方式（銀行、製薬、航空宇宙、CPG） — フェーズの定義、リンクされたレコードの Compliance Checks、フェーズごとの Approver フィールド、監査履歴のロールアップを含む Stage-Gate テーブルを追加します。「段階的な承認が必要です」という要望や、規制業界を示す情報があれば提案します。
• M&A 持株会社（複数企業のポートフォリオ） — Acquired-Companies、Deal-Pipeline scoring、External Onboarding Portal インターフェースを追加します。「複数の子会社を運営しています」という要望や、買収関連の用語があれば提案します。

5人のチームに Airtable の7テーブル構成を押し付けないでください。プロダクトチームが6つあるエンタープライズ顧客に、3テーブルの MVP を提供しないでください。回答に合った構成を選んでください。

ビルドレイヤーの判断

セットアップモードのスキルは、ウォーターフォールではなく、並行する4つのレイヤーで構成されます。

1. スキーマレイヤー（常にMCP経由） — ベース、型付きフィールド、リンクされたレコード、数式、シードデータです。基盤となるレイヤーであり、どの経路でもここを通ります。特定のネイティブビューやインターフェースコンポーネントでの利用を想定したベースを作成する前に、該当する画面の最新のスキーマ要件と動作について、関連する support.airtable.com のドキュメントを WebFetch で取得してください。スキーマを公式モデルに合わせることで、「正しく見えるのに表示されない」という失敗を防げます。
2. AirtableネイティブUXレイヤー — ビュー（カンバン／カレンダー／ギャラリー／タイムライン／ガント／リスト）、インターフェースデザイナーのページ、自動化、フォーム、詳細な権限、同期セットアップウィザード（Jira／Salesforce／Zendeskなど）です。現在作成できるものにはMCPを使い、それ以外は [click here] のUI設定手順として引き継ぎます。境界は機能の違いによるもので、品質の優劣ではありません。MCPがある画面に対応したら、MCPを使う方法を優先してください。「MCPでできること、できないこと」の固定リストを前提にするのではなく、mcp.airtable.com/mcp のライブMCPを照会して、現在のツールの範囲を確認してください。
3. Airtable Portalsレイヤー（中間の選択肢――ノーコードのブランド付き外部アクセス） — カスタムブランドのサインインページを通じて、外部のコラボレーター（顧客、パートナー、ベンダー、請負業者）に公開するインターフェースです。編集者／コメント可／読み取り専用の権限と、現在のユーザーによる行レベルのフィルタリングに対応します。有料アドオン（Team／Business／Enterprise）です。ブランド付きサインインページはBusiness以上およびEnterpriseで利用でき、読み取り専用のポータルユーザーは課金対象外です。1つのベースにつきポータルは1つです。プランごとの最新の詳細については、ここに数値を記載せず、実行時に support.airtable.com を参照してください。 適している用途：画面にブランドを表示する必要がある顧客フィードバックポータル、パートナー向けの読み取り専用ロードマッププレビュー、外部関係者向けダッシュボードです。完全に公開され、認証なしで誰でもアクセスできるユーザーには対応していません。ポータルユーザーはメール招待または共有可能なリンクからサインインします。匿名でアクセスできる画面やSEOインデックス対象の画面には、レイヤー4を使用してください。
4. カスタムアプリレイヤー（REST API＋エージェントが構築するUI） — Vercel上のNext.js／Reactアプリ、Slack／Discord／Teamsボット、スケジュール実行スクリプト、ユーザー既存のプロダクト内に埋め込む画面です。Portalsでは要件に合わない場合に使用します。たとえば、完全に公開された未認証ユーザー（マーケティング品質のブランド表現を備えた公開ロードマップビューアー）、インターフェースデザイナーのコンポーネント群では実現できないUX（複数ステップのウィザード、埋め込みグラフ、アニメーション、独自のデザインシステム）、顧客のマーケティングサイトに合わせた独自ドメイン上のブランドUX、ユーザー既存のプロダクト内への埋め込み、チャットを使ったワークフロー（Slackのフィードバックボット、Teamsのリリース状況ワークフロー）などが該当します。

外部向けの画面では、Portalsとカスタムアプリの両方を提示し、ユーザーに選んでもらってください。 どちらかが常に既定の選択肢というわけではありません。Portalsは有料アドオンですが、コンポーネント群がワークフローに合えば構築時間を短縮できます。カスタムのVercelアプリならデザインを完全に制御でき、構築とホスティングに必要な余力があればアドオンも不要です。予算、デザイン要件、エンジニアリングの対応力、リリースまでの時間といった制約は、スキルよりもユーザーのほうがよく把握しています。ユーザーがカスタムUIを指定せずに「Xを追跡したい」や「Yを管理したい」と言った場合は、Airtableのネイティブ機能を優先してください。答えが明確でない場合は、ユーザーに確認してください。これは技術的な詳細ではなく、実際のプロダクトに関する判断です。

具体的なパターンについては、references/build-shapes.md を参照してください。Vercel上の顧客フィードバックポータル、公開ロードマップビューアー、Slackのフィードバック受付ボット、Portalsとカスタムアプリのトレードオフを詳しく説明しています。

作業モード：既存のベースを操作する

すでに存在するベースに対してユーザーがスキルを実行した場合（「今週のフィードバックをトリアージする」、「Q3リリースの告知を準備する」、「これらの機能リクエストを評価する」など）は、希望するサブワークフローを特定し、MCP経由で実行（フィルタリング、評価、更新）してから、show-airtable-link で結果を引き継いでください。

主要なサブワークフロー

大半の呼び出しに対応する、10 種類のサブワークフローです。それぞれの詳細な手順は references/sub-workflows.md に記載されています。必要に応じて該当するセクションを読み込んでください。

1. ロードマップとポートフォリオ管理 — チーム横断のイニシアチブ追跡、OKR との連携、ステータスの可視化、経営層向けダッシュボード。最も一般的な呼び出しです。
2. 顧客の声／フィードバックの統合 — 複数チャネルからの受け付け（NPS、サポートチケット、Slack、営業メモ、アプリ内フィードバック、通話の文字起こし）、製品領域やテーマ別の分類、需要に基づく優先順位付けのための集計件数を含む、フィードバックと機能の紐付け。
3. エンジニアリングトラッカーとの連携レイヤー — 戦略策定には上流の Airtable を、実行には下流の Jira ／ Linear ／ ADO を使用します。エピックレベルで双方向に同期し、経営層や GTM 向けに、人が使いやすい表示レイヤーとして Airtable を活用します。すでにエンジニアリングトラッカーが導入されている場合によく使われるパターンです。
4. 製品ローンチ／GTM の調整 — リリースのグループ化、依存関係を含む UAT ／本番稼働の追跡、フォームによる顧客承認、部門横断のタスク追跡、経営層向けのリリース状況ダッシュボード。
5. OKR との整合と戦略計画 — イニシアチブと OKR のマッピング、経営責任者別の月次ポートフォリオ集計、モバイル対応ダッシュボード。
6. 単一 PM ツールの置き換え — 明確な移行の経緯を示します。よく置き換え対象となるツール：Productboard、Aha、Cycle、Monday、Smartsheet、Notion、Miro。「競合製品の 1 つ」ではなく、「単一目的の PM ツールを丸ごと置き換える」と位置付けます。
7. キャパシティ／リソース配分のモデル化 — 計画と実績のキャパシティ集計、依存関係を考慮した再計画、優先順位の境界を変えたシナリオ、エンジニア 1 人あたりの四半期稼働日数。
8. 顧客向けロードマップポータル — プレビュー／ベータ版の可視化、投票、購読機能を備えた、公開またはパートナー向けのロードマップビュー。例外的なケースではなく、よくある形です。カスタムアプリの構築レイヤーが適しているのは、通常このケースです。
9. 構造化スコアリングによるアイデア受付のゲート管理 — RICE ／ WSJF ／ Lean Canvas による受付。無秩序な受付の混乱を防ぐため、構造化された提出を徹底することを重視します。
10. 部門横断のリリース告知自動化 — 外部チャネルへのリリースノートの自動公開、元の投稿者へのフィードバック通知による対応状況の共有、隔週のステータスリマインダー。

ユーザーがエージェント主導のワークフローを明示的に構築している場合に紹介する価値のある、オプトインのエージェント状態管理パターンもあります。

11. エージェント活動ログパターン — ユーザーがエージェント主導のワークフロー（定期的なトリアージ、複数ステップの計画、長時間にわたって実行されるエージェントなど）について説明した場合は、オプトインの Agent activity log パターンを紹介し、agent-activity-log スキルを組み合わせて、その構築と運用を支援します。スキーマをインラインで再実装しないでください。永続的なエージェント基盤としての Airtable の役割と自然に組み合わせられます。

references/sub-workflows.md には、さらに約 12 種類のサブワークフローが参考情報として用意されています（PLM 周辺、外部パートナーのロードマップ追跡、ERP 導入前の準備ハブ、実験ライフサイクルハブ、R&D 参加者管理、経営層向け機能投票、SKU の合理化、営業支援用の競合対策資料、M&A による買収後のオンボーディング、ステージゲートガバナンス、SAFe ／ PI 計画のオーケストレーション、主要な成果指標を段階的に集計する成果ベースのロードマップ）。必要な範囲が明らかになった時点で読み込んでください。

構成

このスキルは4つの関連スキルと連携します。それぞれの役割を重複して実装しないでください。

• show-airtable-link — セットアップモードのビルドプランはすべてベースへのリンクで終わります。レコードに触れる作業モードの操作はすべて、レコード／テーブル／ページへのリンクで終わります。必ず連携してください。作業完了後、show-airtable-link を使ってクリック可能なリンクを返します。ツール呼び出しでアクセスが確認された、最も具体的なURLを引き継いでください。
• agent-activity-log — ユーザーがエージェント主導のプロダクト運用ワークフロー（定期的なフィードバックのトリアージ、複数ステップの計画、長時間にわたるエージェントの実行、「エージェントが変更案を提示し、私が承認する」「この優先順位付けに至った経緯を記録するエージェントのログ」など）について説明した場合は、オプトイン可能な Agent activity log パターンを紹介し、このスキルと連携して構成を作成し、運用してください。ワークフローでレコードに触れるテーブル（Roadmap、Customer feedback、Releases、OKRs など）を引き継ぎ、対象ごとのリンクレコードフィールドを正しく構成できるようにします。スキーマをインラインで再実装しないでください。
• airtable-filters — 作業モードの操作でレコードを絞り込む場合（トリアージキュー、「P0 機能を探して」、キャパシティの集計など）は、フィルター構文を独自に導き出さず、このスキルと連携してください。
• airtable-overview — ユーザーが基本的なデータモデルの概念（ベース／テーブル／レコード／インターフェースページ）について混乱している場合に限り読み込みます。ほとんどのユーザーには不要です。デフォルトで読み込むとトークンを無駄にします。

権限を考慮した動作

MCP ユーザーの認証によって、実際に開ける URL が決まります。ツール呼び出しで確認できたアクセス範囲を守ってください。

• ページ制限付きユーザー（Airtable の権限モデルでインターフェースのみアクセス可能） — インターフェースページの URL のみを引き継ぎます。ユーザーが開けない tbl_* URL は、そのユーザーにとって無効なリンクです。
• テーブルレベルのアクセス権 — テーブル URL を安全に共有できます。
• ワークスペースレベルのアクセス権 — ワークスペース URL を安全に共有できます。

基本ルール：ツール呼び出しでアクセス範囲を確認できていない場合は、リンクを貼らないでください。迷った場合は、具体性を1段階下げてください。URL を引き継ぐ際には show-airtable-link スキルがこのルールを適用します。

ビルドプランの出力

該当するレイヤーに応じて、3種類の出力形式があります。ユーザーが実際に求めているものに合わせて選んでください。過剰に構築せず（「プロジェクトを管理したい」にカスタムアプリを作らない）、不足もさせないでください（「顧客向けポータル」を求められているのに UI 操作のリストだけにしない）。

以下の Configure in Airtable または Configure Portal ブロックに項目を記載する前に、mcp.airtable.com/mcp で稼働中の MCP を確認し、現在の対応状況を調べてください。MCP が本来なら引き継ぐ必要のある画面（ビュー、インターフェースページ、自動化、フォームなど）を作成できるようになっている場合は、代わりに MCP の方法を使用してください。MCP の機能範囲は急速に拡大しています。今日 UI での引き継ぎが必要なものでも、明日は MCP で操作できるようになる可能性があります。

Airtable のみ（最も一般的 — ユーザーがネイティブな体験を求めている場合）：

✅ Built (via MCP):
  - [Base name] with [N] tables, [N] fields, linked records, [N] seed records
  - View in Airtable: [base link]

🎨 Configure in Airtable:
  - [Specific Kanban / calendar / gallery view] — [click here]
  - [Specific interface page for the right stakeholder audience] — [click here]
  - [Specific form / automation] — [click here]

Airtable + ポータル（カスタムアプリを構築せずに、顧客／パートナー／ベンダー向けのブランド化された外部アクセスをユーザーが求めている場合）：

✅ Built (via MCP):
  - [Base + schema]
  - View in Airtable: [base link]

🌐 Configure Portal:
  - Enable Portal on the [Customer feedback intake / Partner roadmap] interface — [click here]
  - Customize branded sign-in page (logo + background) — [click here]
  - Invite first portal guest(s) — [click here]

🎨 Configure in Airtable:
  - [Admin interface page for internal triage] — [click here]
  - [Automation tying portal events to internal workflow] — [click here]

Airtable + カスタムアプリ（公開ロードマップ、マーケティング品質のブランド、埋め込み画面、またはその上で動作するチャット画面のボットをユーザーが求めている場合）：

✅ Built (via MCP):
  - [Base + schema]
  - View in Airtable: [base link]

🛠️ Custom app:
  - [Next.js portal at vercel-deploy-url]
  - Reads / writes [tables] via Airtable REST API
  - PAT scoped to [scopes]
  - Source: [github-repo-link]

🎨 Configure in Airtable:
  - [Admin interface page for triage] — [click here]
  - [Automation tying app to base events] — [click here]

最も影響の大きい UI での引き継ぎを1〜3個選び、考えられるすべてのビューを列挙しないでください。ユーザーはベースに入ってから追加を依頼できます。

アンチパターン（デフォルトにしてはいけないこと）

以下は、データが裏付けていない前提をデフォルトにしてしまう、繰り返し発生する失敗パターンです。

• テック系プロダクトチームを前提にしないでください。 業界の多様性が基本です。銀行、アパレル、製薬、メディア、航空宇宙、エネルギーなど、さまざまな業界で Airtable を使ったプロダクトオペレーションが行われています。「プロダクト」が「ソフトウェア製品」を意味すると決めつける前に、幅広く確認してください。
• ユーザーが Jira を使っていると決めつけないでください。 Jira を使っている人は少なくありませんが、多数派ではありません。まずスキーマを構築し、エンジニアリング向けトラッカーとの連携については追加の質問として確認してください。
• Slack を使っていると決めつけないでください。 医療、自動車、EU の企業、そして多くの大規模な非テック系組織では、Microsoft Teams のほうが一般的です。
• フィーチャーフラグや実験から話を始めないでください。 これらのワークフローは専用プラットフォーム（Statsig、LaunchDarkly）で管理されており、実際のプロダクトオペレーション向け Airtable 環境ではほとんど使われていません。ロードマップ、フィードバック、ローンチ、OKR、キャパシティに絞ってください。
• Claude や OpenAI を利用できると決めつけないでください。 承認済みベンダーの LLM に関する制約は現実に存在します（Gemini のみ、または一部の企業ではサードパーティの LLM は利用不可）。特定のプロバイダーにひも付いた AI 連携を推奨する前に、確認してください。
• 軽量なケースを過小評価しないでください。 5 人のチームがバックログテーブルを 1 つだけ使うのも、実際に存在する典型例です。そのようなチームに標準的な 7 テーブルのスキーマを押し付けるのは、行き過ぎです。
• MCP が現在サポートしていることには MCP を使い、それ以外は [click here] という UI 手順に引き継いでください。 MCP が実際に何を作成できるのか、あるいはできないのかを決めつけず、実行時にライブの MCP に問い合わせてください。境界は機能面のものであり、時間とともに狭まっています。品質の選択によるものではありません。引き継ぎの理由を「UI のほうがうまくできるから」と説明しないでください。
• ユーザーが本当に必要としていない限り、REST API の段階へ誘導しないでください。 ネイティブの Airtable で、ほとんどのプロダクトオペレーションの構成にうまく対応できます。カスタムアプリ層が適切なのは、一般公開向け、ブランドに合わせたもの、埋め込み型、またはチャット経由のものをユーザーが求めている場合です。「ロードマップ用のベース」を求めている場合ではありません。

どの進め方を選ぶべきか迷ったら、質問してください。スコープに関する質問にかかるのは 10 秒ですが、誤った構成を作り直すには 1 時間かかります。