Coding Agent時代のドキュメントについて考えていること
こんにちは！逆瀬川ちゃん (@gyakuse) です！ 今日はCoding Agent時代のドキュメントについて、最近考えていることを書いていきたいと思います。悩み中なので、荒れた内容になっていますが、ご容赦を。コード規模、チーム規模などなどによって、正解は異なるものだと思います。あくまで私の実践の一例として読んでくれれば幸いです。 以前書いたCoding Agent時代の開発ワークフローやClaude Codeのシステムプロンプト解説記事でCLAUDE.mdやAGENTS.md、ADRの運用について少し触れましたが、そもそもドキュメントって何のために書くんだっけ、Agentが読むドキュメントはどうあるべきなんだっけ、というところをもう少し掘り下げて考えたいなと思っていました。まだ結論が固まっているわけではないのですが、最近の実践から見えてきたことをまとめてみます。 そもそもドキュメントの
Claude Code を活用した電子カルテの外部連携仕様書メンテナンス自動化の取り組み - 株式会社ヘンリー エンジニアブログ
この記事では、Claude CodeのSkill(Agent Skill)やCIを活用して、コードベースから外部連携の仕様書を自動生成・更新する仕組みを構築した取り組みを紹介します。 はじめに こんにちは！ヘンリーで電子カルテ開発チームでエンジニアをしているわくわく(@wakwak3125 / @wakwakjp) です。 最近社内でのAI活用が進んでいており、 https://dev.henry.jp/entry/claude-code-orchestrator のような便利なSkillのおかげで開発自体の速度がぐんぐん上がっています。 一方で、まだまだ人の手で行われている部分が多いのも事実です。今回はその人力で行われていて、抜け漏れのチェックが非常にめんどくさい「仕様書」と呼ばれるもののメンテナンスを Claude Code, Skill, GitHub Actions を使い半自動化
Hono CLI 爆誕
これまでHonoは数々の新しいことを提供してきました。正規表現を活かしたルーター、サーバーサイドの軽量JSX、TypeScriptの型によるRPC、Web Standardを使ったマルチランタイム対応などなど。アイデアと実装力で世界と戦って来たわけです。 本日私達が紹介するのは「Hono CLI」です。 Hono CLIは全く新しいコンセプトのコマンドラインインターフェースです。 create-* ではありません ただの開発用（dev&build&deploy）のコマンドではありません Viteのラッパーではありません 人間とAIのためのCLIです。インストールすると のようにhonoコマンドを使うことができます。5つのサブコマンドがあります。 hono docs hono search hono request hono serve hono optimize では一つ一つを見ていきまし
画面仕様書への静的検査器を実装したらたくさんの欠陥を発見できた話 - DeNA Testing Blog
SWET第二グループのKuniwakです。本記事では画面仕様（後述）の仕様書に対する静的検査器を開発した事例について紹介します。 伝えたいこと 画面表示と画面遷移を記述する仕様書は機械可読にできる 仕様書が機械可読であれば仕様の静的検査ができる 静的検査によって自身の担当範囲の15%の画面から計40件弱の欠陥を発見した 機械可読な仕様書にはさらなる応用が見込める おさらい：仕様とは 仕様の定義はいくつかあります。 ここでは仕様とは実装の正しい振る舞いを定める基準とします。 ある実装が正しいと判定されることを、実装が仕様を満たしたといいます。 誰による判定でも実装が仕様を満たしたかどうかの判定結果は一致すべきです。 さて実装の欠陥と同様に、仕様にも欠陥が生じえます。 本来正しいと意図した実装の振る舞いを誤っていると判断したり、その逆に誤っていると意図した実装を正しいと判断する仕様には欠陥があ
React Router v7でコードを書いてくれSonnet
Claude 3.7 Sonnetに代表される現在の主力なコーディングモデルやソフトウェア開発タスクの自動化に利用されるLLMは、知識のカットオフにより2024年後半頃までにネット上に存在する情報をもとにしたソースコードしか書くことができない。例えばAnthropicのAPIを直接利用して確認すると、「React Routerの最新バージョンはv6です」と返答が来る。しかし、最新版はv7だ。v7.0.0はちょうどこの時期にリリースされたため境界にあり、つまりv7の実践的な知識はない。これに限らず、LLMの世界ではNext.jsはv14、Flaskはv2、Railsはv7と一世代遅れたバージョンを認識していることになっている。 これらのアップデートによって入った変更は、既存のソースコードに記述していればLLMが空気を読んで従う。加えて、ユーザーがカスタムルールとしてエディタ側で追加情報を設定
Copilot Edits の機能を補うscript, promptを試している
目的と概要 Copilot Edits を使っていて、以下の課題を感じていました。 最新の技術情報を参照させるのに手間がかかる 会話ログが残らないため後から参照できない ドキュメントの整理方法が確立されていない これらの課題を解決するため、簡単なスクリプトとプロンプトパターンを作成したので紹介します。 ディレクトリ構成 効率的に作業するため、以下のようなディレクトリ構造を採用しています。 . ├── ai-out/ # Copilot Edits 作成のドキュメント ├── chatlog/ # Copilot との会話ログを保存 └── refs-docs/ # 参照用のドキュメント └── {domain}/ # ドメインごとにドキュメントを整理（例: github, docs.example.com） └── {path}/ # 元のパス構造を維持（URL のパスと同じ構造）
Clineに自分をエミュレートさせて技術記事を代筆させてみたらビビった
なんか驚き屋っぽくてアレなんだけど、今回はさすがに驚く権利があると思うので、至急記事を書く。 やろうとしたこと 毎回手元の検証結果から技術記事を構成するのがだるい 自分のブログを適当に読ませておいて、その構成と文体を真似させればいいのでは 手元に mizchi/zenn というリポジトリがあり、ここに zennにポストする原稿を管理している。 $ tree ./articles ./articles ├── 1c35fdcc77065c02f631.md ├── 3e4742e24f2ca0118f70.md ├── 8a017097d3994ddc0a85.md ├── ai-code-generation.md ├── ai-programmer.md ├── ai-team-mate.md ├── antipattern-of-tournament-score-sheet.md ├─
Slackの会話からドキュメントを育てるGo製AIエージェント「Docgent」を開発しました
※この記事は「AI Agent Hackathon with Google Cloud」向けに開発したAIエージェントの説明のために作成したものです。 前書き 現代のソフトウェア開発組織では、素早く高頻度で機能追加・改善していくことが求められると同時に、LLMの時代においてはAIによる利活用を見据えて 「ドキュメンテーション」の重要性が高まってきています。 しかし、「包括的なドキュメントよりも動くソフトウェアを[1]」重視するアジャイル開発を実践する中で、 忙しない日々の中でどうしても残すべきドキュメントを残せない 過去に書いたドキュメントの古い内容がアップデートされず放置されていて当てにならない という組織も少なくないと思います。 きっと今日もどこかの組織のSlackでは、他の部署や開発チームから仕様確認の問い合わせが寄せられ、それらに人手で回答する努力が積み重ねられていることでしょう（
社内コミュニケーションを支える用語集「Words」
こんにちは、LINEヤフー株式会社でテクニカルライターとして働いている古木です。私は、LINE Developersサイトの技術ドキュメントやAPIリファレンスを書く専門職としてライティングを行う傍ら、社内用語集の管理にも携わっています。 今回は、LINEヤフーの社内用語集「Words」のご紹介を通じて、社内用語集サービスの立ち上げについてや、運営方法についてお話しします。 Wordsとは何か Wordsは、社内用語と分野別の専門用語を、テクニカルライターがわかりやすく解説した用語集です。韓国のLINE PlusとLINEヤフーのメンバーが協業して、運営を行っています。 Wordsは、社内のさまざまな部門やプロジェクトで使用されている用語とその説明を一箇所に集めて、検索しやすくすることで、社内のコミュニケーション効率を向上させています。特に、社内用語を初めて目にする新入社員が安心して業務に
個人開発でもADR （アーキテクチャデシジョンレコード）を書くことの利点 - laiso
起業なのか請負開発か趣味のプロジェクト（ペットプロジェクト）かによって状況は異なりますが「私のチームの開発者は私１人だけです」という個人開発においても、ADRは有効なツールとなりえます。 ADRとは何か？ ADR（アーキテクチャデシジョンレコード）は、ソフトウェアアーキテクチャにおける重要な設計判断とその根拠、影響、関係する検討事項などを記録した文書です。 一見、現代的な響きですが、その実態はシステム設計ドキュメントの一部です。 "ADR"で検索すると真っ先にヒットするアーキテクチャの入門書『Design It! ―プログラマーのためのアーキテクティング入門』では、ADRは「アーキテクチャ手法に対する開発者寄りのアプローチ」と説明されており、アーキテクトと開発者自身がアーキテクチャに関する意思決定を記録し、共有するための手法として位置づけられています。 アーキテクチャデシジョンレコード（A
Starlight 🌟 Astroでドキュメントサイトを作る
最高のドキュメントサイトを作るために必要なものがすべて揃っています。高速でアクセシブル、しかも使いやすさも備えます。
API Improvement Proposals
Welcome AIPs are design documents that summarize Google's API design decisions. They also provide a framework and system for others to document their own API design rules and practices. AIPs are a combination of design guidance and a system we use to manage and track that guidance. Learn more about how the AIP program works in the first AIP!
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
要求定義・仕様記述・設計・検証の手引き - 理論から学ぶ明確で統一された成果物定義
Future Enterprise Arch Guidelines
ドキュメントを手作業で保守する時代は終わり ～Google、「Code Wiki」を公開プレビュー／公開リポジトリのドキュメントを継続的に自動生成、「Gemini CLI」拡張機能も開発中
マネージャーこそ真剣に考える 「情報量の差」を意識したオンボーディング
readme.so
GitHub - k1LoW/tbls: tbls is a CI-Friendly tool to document a database, written in Go.
ADRを運用して3年経った僕らの現在地
Design Doc の書き方 / How to Write a Design Doc (Ja ver.)
