■ 1. No Codeの終焉
- Airtable買収という節目:
- Bending SpoonsがAirtableを12.8億ドルで買収した
- ローマは一日にして崩れないが、No Codeプラットフォームが最盛期を過ぎた瞬間を示す地点として妥当
- 立場の開示:
- 自分はAirtableに長年在籍し、製品を愛し、共に働いた人々をそれ以上に愛している
- 変わったのは技術であり、ツール使用を伴うLLMループの理不尽なほどの有効性が原因
■ 2. 業務ソフトウェアの本質
- ソフトウェアは手段:
- 職場のソフトウェアはそれ自体に価値はなく、何らかの目的に奉仕するために作られる
- 用途の大半は何かを記録し管理することであり、スケジュール、部品、注文、人などが対象
- スプレッドシートの天井:
- 表計算はこの領域における普遍的なソフトウェアであり、自分自身も愛用する
- 共有、プログラミング、権限、自動化などの面で限界がある
- データベースへの昇格:
- スプレッドシートを離れるとデータベースとその上のソフトウェアに移行する
- それがAirtableのようなローコード/ノーコードプラットフォームの正体
- 導入者が運ぶもの:
- チームにAirtableを持ち込む人が本当に持ち込んでいるのはAirtableではない
- 切実に必要とされる組織化とプロセスであり、Airtableは単なる手段
■ 3. Airtableが正しかった点
- テーブル作成の体験:
- Excelのように列を追加し、データ型として文字列、数値、日付などを選ぶだけでテーブルが完成する
- ALTER TABLE widgets ADD COLUMN (color string)というウィジェットを持たない方式の有効性を、データベースの大規模学会SIGMODで発表すべきだと冗談を言っていた
- Fred Brooksの洞察:
- フローチャートを見せられテーブルを隠されたままでは謎は解けない
- テーブルさえ見せられればフローチャートは通常不要で、自明になる
- ユーザーがビジネスモデルを自ら記述できれば、その上に自動化や機能を作ることが可能になる
- 発想自体は新しくない:
- FileMakerは1985年に登場し、自分にとってのデータベース入門でもあった
- 約1,600人の高校生向け会議の運営では、わずかな加点と新入生とAppleTalk接続の3台のコンピュータで郵送の登録用紙を処理できた
■ 4. IT部門とSaaSの歴史
- 90年代の自社開発:
- 企業のIT部門は自社のためにソフトウェアを作る存在であり、多くは個別受注的な開発
- SaaS台頭の里程標:
- Salesforceの2000年の「Software is Dead」キャンペーンがSaaS支配の始まりを示す目印
- IT部門の仕事は調達となり、調達とはNOと言うことを意味する
- 穴を埋めた道具:
- ローコード/ノーコードプラットフォーム、Microsoft SharePoint、Excel、Google Sheetsが不足を補った
- ソフトウェアを買えないとき、人はアクセスできるもので間に合わせる
- 撤去できなくなる構造:
- Airtableを密かに持ち込み、売上や効率や信頼を向上させる
- 一度荷重を支える存在になると、官僚的な理由で誰もそれを排除できなくなる
■ 5. インフラという障壁
- EC2登場後も残った壁:
- AWSは2006年にEC2を開始し、VMを借りられるようになった
- 同僚と何かを共有するためにインターネットへ出すには、EC2 VPC、IAM権限、EBS、RDS、静的IP、DNSなど多数の三文字略語の学習が必要だった
- ソフトウェア企業内でも同じ:
- ソフトウェア企業の内部ですらIT部門がEC2をゲートキープしていた
- 2007年のGoogleでは、社内コードベースの検索ツールがJeff Deanの机の下の予備デスクトップで動いていた
- 自分にとって決定的に重要なこのインフラをデータセンターのマシンで提供させるのは、手間が大きすぎた
■ 6. 2026年の答えはLinux
- 現在の問い:
- LLMが王であり、SaaSの終末は破産と同じく徐々に、そして一気に進行している
- 業務ツールを構築しデプロイする正しい方法と正しいプラットフォームは何か
- ソフトウェアエンジニア以外の人間に任せられるかどうか
- 退屈な技術を選ぶ:
- 正しい答えはLinuxであり、退屈な技術を選んでLinuxを使えばよい
- Linuxの上のスタックは選択肢が多く、LAMPを選んでも何の問題もない
- 現在の好みのスタック:
- 自分の現在の選好はsqlite、Go、TypeScript、場合によってVue
- メモリが高価でなければPostgreSQL、Node、TypeScriptでも問題ないが、メモリ逼迫は現実の制約
- コードを自分で書かない以上、フロントエンドとバックエンドで単一言語を使う利点は消滅した
- ロックインの弱さ:
- スタック全体がオープンソース
- AWS、GCP、Render、Azure、Oracle Cloud Infrastructure、Railway、Hetzner、miniPCのいずれに移行してもデータとコードをrsyncすれば済む
- プラットフォームレベルのロックインはローコードプラットフォームに比べて弱い
- 既存のローコード構成も、エージェントに数回プロンプトを与えればLinuxへ移植される
■ 7. exe.devのアプローチ
- 提供するもの:
- サブスクリプションでLinux VMを作成でき、意味のある形でインターネット上に存在する
- 友人にリンクを送れば、そのリンクは機能する
- デフォルトで安全であり、自社の認証システムまたは独自の認証でサイトを公開できる
- 高速であり、コーディングエージェントに適する
- 本番で直接作る:
- カスタムソフトウェアはコーディングエージェントとともに本番環境でそのまま構築する
- 使えるものになるまで反復し、同僚のフィードバックでさらに反復する
- 同僚自身にも反復させ、粗い部分を削らせる
- エージェントに与える情報:
- ビジネスのデータモデルとワークフロー、可能ならスタックの示唆を与えれば、エージェントは十分にこなす
- 例外となる1%:
- 業務上決定的に重要な領域へ昇格が必要な1%のプロジェクトなら、2台目のVMと開発環境を用意する
- 現代的ソフトウェア開発の紛らわしい装置であるgitに進んでもよい
- low floor, high ceiling:
- Linux上で動くLLMは究極の「low floor, high ceiling」
- まず始めさえすれば、スプレッドシートを置き去りにできる
■ 8. FAQ: セキュリティと移行
- データの安全性:
- デフォルト設定が安全であり、仕組みはGoogle Sheetに酷似する
- VMのWebポートをチームだけ、個々の相手、あるいは全世界に共有できる
- 既存資産の移植:
- VMを起動し、デフォルトでプリインストールされたエージェントShelleyのもとを訪れる
- 既存ソリューションのAPIキーを渡すか、スプレッドシートをアップロードする
- このマシン上のWebアプリケーションへ移植するよう指示すれば、実行される
- 現時点ではモデルとしてSolかOpusを使い、答えは頻繁に変わるので今後はDiscordで尋ねればよい
■ 9. FAQ: 自動化とエージェント
- スケジュールと自動化:
- Linuxは豊かなプラットフォームであり、エージェントにタイマー実行を依頼すれば実現される
- 通常はsystemdが選ばれるが、cronを好むなら誘導すればよい
- どちらも知らなくても問題はない
- エージェントやボットの構築:
- 「exe.devのLLM統合を使ったエージェントループ」を、必要なツール付きで書くようエージェントに依頼する
- 特定チャンネルのSlackスレッドを読んでコメントするような実装を、エージェントはワンショットで仕上げる
- Integrationsシステム:
- exe.devプラットフォームの最良の点の一つ
- ボットをSlackへ接続することがかつてないほど容易になっている
■ 10. FAQ: 品質と方法論
- Vibe Codingの十分性:
- 自分の経験では十分に通用する
- 通常はリスクとリターンを測る話であり、スプレッドシートの数式はどれも脆く未テストでありながら現に機能している
- フレームワークの要否:
- 好きなフレームワークを使えばよいが、最終的にエージェントは自ら選ぶか、退屈な方法で片付ける
- ベストプラクティスは世界中で無数に矛盾している
- 「P & L FINAL FY2025 FINAL VERSION 3」が依然として中央値の解であり、まず自分のワークフロー要件を見極めるべき
- データベースをどこかへバックアップするcronジョブもエージェントに設定させておく
- 性能とテスト:
- エージェントは自らの成果物のテストと性能問題の修正の双方で驚くほど優秀
- 自分が使うのと同じプロファイラなどのツールを使う
- Shelleyの秘密兵器は使いこなせる優れたブラウザツールであり、プロファイラ、スクリーンショット、スクリーンキャストを備える
■ 11. FAQ: 価格
- 基本プラン:
- 月額20ドルで最大50台のVMを利用でき、各VMは2CPUと8GBメモリに制限される
- チーム向けの小さなアプリなら十分な規模
- 拡張と課金:
- より多くのリソースが必要ならアップグレードするか相談すれば、必要な大きさのマシンを用意する
- 構築にサブスクリプション付属分を超えるLLMトークンが必要になる場合がある
- ChatGPTのサブスクリプション、他のコーディングエージェント、他のモデルプロバイダを接続でき、APIトークン原価での提供も可能