小規模な制作チームがClaude Opus 5.5を使い、台本の執筆、メディアの添付、編集者との共有、アイデアの収集をまとめた社内アプリを1つ作りました。狙いは既存ソフトウェアの機能をすべて再現することではありません。チームが頼っていた少数の機能を1か所に集めることでした。
この違いは、複数のSaaS（software as a service、オンラインで提供されるサブスクリプション型ツール）に料金を払いながら、それぞれのごく一部しか使っていないチームにとって重要です。今回のケースでは、Notion、mymind、Typefully、Google Driveで扱っていた業務を含め、5つの有料サブスクリプションを置き換えることを目指しました。年間約$4,000の節約という見積もりはこのケースに限った数字であり、ほかのチームが同じ結果を期待できるものではありません。
ツールを手放せない理由となっている業務を軸に作る
これらの製品を2年間使った後、チームは利用できる機能のうち実際に使っているのは約10%だと見積もりました。Notionが欠かせなかった主な理由は、特定の箇所に結び付いたコメントと、裏付けとなる画像や動画を台本に添えて編集者に渡す必要があったからです。Google Docsを使った作業では、メディアを多く含むこうしたコメントを必要な形で扱えないとチームは判断しました。一方で、データベースやブロック、設定が入り組んだ大きな仕組みの使い方を新しいメンバーに教えるのにも時間がかかっていました。
独自アプリでは台本を中心に据えました。書き手は行や段落にコメントを付け、そのコメントに画像や再生可能な動画クリップを添付できます。編集者は別のファイルを台本と照らし合わせる必要がなく、該当する箇所のすぐ横で素材を確認できます。さらに外部の編集者には閲覧専用のリンクを送ることができ、編集者は台本を確認したうえで、添付ファイルを圧縮アーカイブであるZIPファイルにまとめてダウンロードできます。
▲ 台本のコメントに添付したメディア
関連する作業も、ほかの画面を通じて同じワークスペースに集めています。メディアライブラリは台本のコメントにアップロードされた素材を集め、それぞれを元の箇所に結び付けます。たとえば「subscriptions」で検索すると、その話題に関連する画像が見つかります。ブックマーク画面には、アイデアを練るために保存したXの投稿が集まります。これまで別々のツールやスプレッドシートで扱っていたXの投稿予約とスポンサー管理も、このアプリで処理します。
これはNotionを作り直すよりも狭い目標です。汎用製品が備えるデータベース構造や数式、例外的なケースへの対応をすべて必要としていたわけではありません。必要だったのは、台本、文脈に沿ったフィードバック、すぐに使えるメディア、そして編集者への受け渡しでした。範囲をこのように絞ったことが、独自アプリを現実的なものにした主な理由と見られます。
AIをアプリの中で働かせる
チームはバイブコーディング（vibe coding）でこのワークスペースを作りました。望む動作を普段の言葉で説明し、AIコーディングツールがソフトウェアを書いて修正していく方法です。開発ではおよそ20回のプロンプトのやり取りがありました。Claude Opus 5.5を5日間集中的に使った間、チームは利用上限に一度も達せず、機能の実装依頼が失敗した例もなかったとしています。これはあくまで今回の開発で確認されたことであり、ほかのプロジェクトや料金プランでの結果を保証するものではありません。
アプリはエージェントネイティブ（agent-native）にも設計されています。AIエージェントがチャットで変更を提案するだけでなく、アプリの作業データを直接更新できるという意味です。Claude Codeは、特定の作業向けにまとめた操作であるスキルを使い、アイデアをアプリのデータベースに直接追加します。ある例では、この処理によって、書式の整った制作テンプレート付きの新しい台本項目が作られました。書き手は別のワークスペースからアウトラインを写すことなく、その項目を開いて書き進められました。
▲ 独自アプリへのAIによる更新
ClaudeのProjectsワークスペースは、コーディングとデザインの作業を別々のスレッドに分けるのに役立ちました。Claude Codeはさらに、インターフェース部品をまとめたFigma風のボードと、台本一覧の3つの代替案（ステータスボード、列で管理するカンバンボード、ダッシュボード形式の表）を作りました。Claude Coworkはアプリを説明する14枚のスライド資料を生成しました。これらの成果物がアプリの中核である編集ワークフローに取って代わったわけではありませんが、同じ作業環境の中でレイアウトを検討し、作ったものを記録することを可能にしました。
この方法で変わること、変わらないこと
一般的なSaaSの導入は、既存の機能一式から出発し、チームにその製品へ業務を合わせるよう求めます。今回の開発はチームが繰り返し行う作業から出発し、必要な部分だけを組み立てました。その利点は、ツールを行き来する手間が減り、チームが使わない機能のための教育も減る点にあると見られます。
この例は、どのサブスクリプションもすぐに置き換えられることや、独自アプリに保守が要らないことを示すものではありません。示しているのは、特定の制作ワークフローに絞った開発です。チームがClaude Opus 5.5を高く評価した根拠は、その作業の間に確認した速度、コスト、信頼性であり、あらゆるアプリやAIモデルを網羅的に比較した結果ではありません。
繰り返す業務を1つ選んで始める
実践上の教訓は、ソフトウェア一式を置き換えようとする前に、小さな目標を定めることです。
- 台本の特定の箇所にメディアを添付できるコメントのように、チームが既存ツールを使い続けている理由となっている機能を特定します。
- その機能の前後で何が起きているかを整理します。今回のケースでは、アイデアが台本になり、コメントが素材を運び、閲覧専用リンクが成果物を編集者に届けていました。
- つながったそのワークフローをまず作り、評価します。AIがアプリ内に記録を作る必要があるなら、そのための決まった手段を用意し、作られた項目がチームの進め方に合っているかを確認します。
Claude Opus 5.5は、このチームが絞り込んだ要件を実際に動く1つのアプリに変える助けになりました。ほかのチームにとって有益な問いは、AIがSaaS製品を丸ごと再現できるかどうかではなく、業務のうちどの小さな繰り返し部分が専用ツールでもっと簡単になるかです。