何が起きたか
Simon Willison氏が、GPT-5.5に「GitHubのコードを埋め込むWeb Componentを作ろう」と指示し、実験的なコンポーネント「github-code」を生成させました。使い方はシンプルで、href属性にGitHubのファイルURL(例: sqlite-ast/parser.py#L9-L18)を渡すだけ。内部でURLをraw.githubusercontent.comに書き換え、fetch()で取得し、指定された行範囲を行番号付きで描画します。シンタックスハイライトは付いていません。
同氏は生成の過程で「作業結果を確認できるようプレビューを表示して」とAIに指示しており、ブラウザ上での動作確認まで含めた開発フローをAIに委ねている点も特徴です。
なぜ重要か
この事例が示すのは、「用途特化した小さな部品」を、外部SaaSやライブラリに頼らず自前で数分で用意できるようになったという現実です。従来ならGistの埋め込みやCarbon、Codesandboxなどのサービス、あるいはPrism.jsの導入といった選択肢が必要でした。しかし今回のように、GitHubコミットハッシュ(例: 437c759...)を含む恒久リンクを直接埋め込める自作コンポーネントを、プロンプト一発で用意できる。
具体的な論点
注目すべきは、Willison氏がハイライトを「あえて実装させなかった」点です。最小機能に絞ることでコード量を抑え、依存関係も排除できる。AIに作らせる開発では「機能を盛らない」設計判断こそが品質を左右します。
💼 事業会社視点：これは自社にどう効くか
事業会社の役員がここから読み取るべきは、「社内向けの小さなツールを外注・SaaS契約する時代の終わり」です。技術ブログを持つSaaS企業やメディア運営部門は、これまで月額数千円〜数万円のコード埋め込みサービスや、CMSプラグイン開発の受託費用を払ってきました。しかし今後、こうした「痒い所に手が届く部品」は、社内エンジニアがAIに数十分で作らせるのが標準になります。
受託開発会社にとっては特に重い意味を持ちます。「GitHubのコードを見やすく表示したい」といった軽微な要件は、もはや発注案件として成立しません。役員が今動くべきは、①社内エンジニアが「作らせる技術」に習熟する時間を業務として認めること、②Web Componentのような標準技術を採用し、フレームワーク依存を減らす設計方針を打ち出すこと、③受託ビジネスを持つ企業は「AIで作れる部分」を単価から切り離した提案モデルへの移行計画を今期中に決めることです。
