update:

• date: 2026-03-03 author: yono content: ブログを公開してわずか1日で、公式が推奨するコンテキストの方法 Copilot カスタマイズチートシート - GitHub Docs を出してきました。もちろん、この記事で紹介する統一方法は Copilot に限らず、どんなAIにも応用できます。

最近の試み

ソフトウェア開発をすべてAI任せにするのは、どんな体験になるのだろうか。

最近、二つの試みを行った。どちらも最新のAIツールではなく、VS Code の GitHub Copilot を使っている。

先に結論

• プロジェクトの立ち上げ段階では、AIに完全に依存するのは当てにならない。最終的なプロジェクトの形について、自分である程度の構想を持っておく必要がある。
• 技術スタックの選定をAIに任せてはいけない。それはプロジェクトの要件に基づく判断というより、ネットのコメントの好みになりがちだからだ。
• 要件が明確に書かれた単一ステップの目標であれば、どのAIモデルでもやり遂げられる。
• 曖昧な全体計画は、AIに一度にすべて生成させてはいけない。細部を何度も繰り返し相談しながら進める必要がある。
• 総じて、UI表示に関する実装をAIに作らせると非常に優秀だが、ロジックを伴う完全なプロジェクトを支えるほどではない。

もう一つの個人的な考え

• プロジェクトの進行は必ずドキュメント駆動にすべき。統一ドキュメントがないと、AIは右脳と左脳が争うように自己矛盾を起こし、トークンを無駄に消費してしまう。
• AIに自分用のコンテキストアーカイブを生成させれば、異なる会話環境でもより一貫した体験が得られる。

その1

その1はクローズドソースのプロジェクトで、要件を記述しただけだ。

Windows 環境で動作するデスクトップアプリが必要です。通信には modbus プロトコルを使います。

タブが2つ必要です。「監視ページ」は「显示参数.csv」をアドレス参照に、「設定ページ」は「设置参数.csv」と「示波器.csv」をアドレス参照にします。

「設定ページ」には「オシロ開始」ボタンが必要で、オシロ開始時に……のロジックを実行します。

適切な技術スタックを選んで、プロジェクトを始めてください。

すべてAIに任せたのは、以下の点だ。

• 技術スタックの選定
• 设计文档.mdの生成
• 初期プロジェクトの起動
• 设计文档.mdに基づいたプロジェクトの推進

プロジェクトに関する全作業は、会話による調整だけで行い、ドキュメントも一文字も手で書かなかった。

このプロジェクトは、私が記述した機能を最終的に実現した。ただし、奇妙な .NET WPF 技術スタックが選ばれ、最後まで出来上がったのは前世紀のUIスタイルで、最適化も極めて難しかった。ずっと Carbon Design System のデザイン言語に変更したかったが、私は WPF が分からない。表示まわりの最適化をAIに依頼しても完遂できず、変更すると大量のバグが発生し、しかもAIはそれを正しく解決できなかった（10回ほどのセッションの末に断念した）。

幸い、社内用の小さなソフトなので、使えればそれでよかった。実験の幕開けとしては悪くない。

その2

その2はオープンソースのプロジェクトとして、将来、我々が独立して立ち上げる会社のポータルサイトとして生まれた。このプロジェクトには、私が想定している技術スタックとフレームワークがある。

Repository · stbanana

ezalive_homepage

ezalive 公司官网试制版,Built on top of Fumadocs.

TypeScript

私はこうやってこのプロジェクトを始めた。

fuma-nama/fumadocs: 美しく柔軟な React.js ドキュメントフレームワーク を調べてください。

今、シンプルで上品な会社ポータルサイトを構築したいのですが、fumadocs は適切なフレームワークでしょうか？

この会社サイトに以下の特徴を持たせたいです。

1. 静的デプロイであること
2. 一般的なホームページの機能をほとんど含むこと。STMicroelectronics のホームページ（https://www.st.com/）のように。
3. STMicroelectronics のホームページを例にすると、あれは Tools & software、Applications、Solutions の3つのタブに分かれている。うちの会社にはそこまでの製品ラインがないので、製品センターのタブを1つだけにしてほしい。もちろん、将来さらに細分化できる可能性は残しておきたい。
4. 多言語対応が必要。基本は中国語 / 英語。
5. GPT、つまりあなたが開発・保守のプロセス全体を一任できること。私は修正意見と内容.mdを渡すだけなので、あなたがすべてのコードを書ける必要がある。fumadocs では不十分だと思うなら、他のフレームワークを提案してもよい。

今はコードを書かないでください。技術スタックの検討段階です。

技術スタックの妥当性を最初に検討したあと、関連情報をひととおり補足する必要があった。コードを書き始めるときの指示は、こういうものだった。

この基本構成は合理的ですが、一部内容を再度確認させてください。今は「リソース/ダウンロード」タブは必要ありません。そういったコンテンツがないので、マニュアルや説明書のダウンロードリンクは製品ページに置きます。

全体像をよりよく理解してもらうための補足情報は以下のとおりです。

1. 会社の主な事業はパワーエレクトロニクス試験器です。
2. 現在の製品は「EZ40004」の1つだけです。これは、ソース/ロード双方向の AC/DC 電源です。
3. ロゴはまだないので、空白の画像をプレースホルダーとして置き、後で直接差し替えられるようにしてください。
4. 配色は fumadocs の公式ドキュメントを参考にしてください。

その後の初版プロジェクト生成では、私が最もよく使った言葉は「続けて」だった。要件と技術スタックの話がまとまっていれば、AIはほとんどすべての作業をやってくれた。

もちろん、AIも急速に進化しており、新旧バージョンで能力や権限が異なる。たまに幻覚を起こして嘘をつくこともあるので、プロジェクトの進捗は慎重に管理しなければならない。このときの会話の一部は、読者に笑ってもらうために記事の末尾に置いておいた。

初版ができてから調整する方がずっと簡単で、エラーも起きにくい。要件を1件ずつ出していくからだ。これにより、AIは設計者の立場からコーダーに切り替わり、細部の実装だけに集中すればよくなる。

人間による関連ドキュメントの確認は今でも欠かせない。AIは、言われたことを鵜呑みにする人をよく騙すからだ。

コンテキスト同期と統一ドキュメントのコツ

要件のあるプロジェクトでは、こうしてAIに作業させる。

在工程中创建 设计文档.md 以便于记录当前的设计。创建 AI/HANDOFF.md、AI/TODO.md、AI/SESSION_LOG.md 文件以便于后续使用“先读取 AI/HANDOFF.md、AI/TODO.md、AI/SESSION_LOG.md 恢复上下文”这样的提示词在更换环境时同步上下文。

上のプロンプトはたいてい、現在のプロジェクトに強く関連した设计文档.mdを生成する。プログラミングとは無関係な説明にはならない。

たまに、設計ドキュメントを技術スタックに依存させず、ソフトウェアの機能とロジックの記述として、別のプログラミングフレームワークで書き直せるようにしたいこともある。そんなときはこういう注記を追加する。ただしその場合、设计文档.mdの手動メンテナンスが必須になる。

在工程中创建 设计文档.md 以便于记录当前的设计。创建 AI/HANDOFF.md、AI/TODO.md、AI/SESSION_LOG.md 文件以便于后续使用“先读取 AI/HANDOFF.md、AI/TODO.md、AI/SESSION_LOG.md 恢复上下文”这样的提示词在更换环境时同步上下文。

注意：设计文档是一种软件功能和逻辑的描述，以便于使用不同的编程框架重构。需要完备描述软件设计的功能，包括已完成和未完成的所有功能，但无需备注是否完成。不要描述技术栈，不要关联当前项目。

ひと区切りついたら、AIにコンテキストの更新を手伝わせる。

现在请更新 设计文档.md以及AI文件夹中的内容,以和当前的项目现状对齐

おおむねそういう考え方だ。結局、プロジェクトを説明するドキュメントが何かしら必要で、それはAIがどんな更新をしても意味があると思う。英語のほうが効果的なのかもしれないが、許してほしい。私の英語力はひどいものなので、AIに甘やかしてもらっている。

ブログ公開から1日後

ブログを公開した途端、公式が推奨の統一コンテキストを追加してきた。くそ、AGENTS.md

AIは人を騙すのが好き

新旧バージョンで能力が異なる可能性はあるが、とにかく今の Copilot はファイルを直接削除できない。以前はできたと思う。

VS Code プラグイン版は GitHub や外部サイトに直接アクセスできませんが、Web版は可能です。