明日、進捗を聞かれて即答できますか
AI に書かせるだけなら、もう誰でもできます。散らかるのが問題です。 それでも仕事が終わらないのは、コードの周りにあるものが全部、人の頭と記憶に残っているからです。 開発を仕事として成立させているのは、下の 8 つに答え続けることです。 どれも「道具が無い」のではなく、道具と仕様が切れていることが問題です。
| いま起きていること | ORQELD の解き方 | |
|---|---|---|
| 要件 | 「これを作れ」がどの要件から出た物か誰も保証していない。着手して初めて「何を作ればいいのか分からない」に気づく | 由来の記載を必須にする。書けない作業は登録できないので、仕様に無い仕事が動き出す前に止まる |
| 仕様 | 現在地が本人の頭の中にしかない。知らずに作った物が食い違い、そのまま正本になる | 問うと値・出典・確度（確定／暫定／不明）が返る。台帳に無ければ「不明」を返し、推測で埋めない |
| テスト | 緑になったことしか分からない。1 本のテストが複数の守りを同時に踏み、互いに隠している | 実装と監査を別々の AI で 2 段に回し、指摘を全部閉じるまで取り込まない。守り 1 つにつきテスト 1 本。管理層にテストの写しは作りません——二重管理を作らないのも設計判断です |
| ユースケース | 仕様書の中に埋もれ、実装との対応が追えなくなる | 仕様の正本を節の単位で参照できる住所として持ち、作業項目からそこへ結ぶ |
| タスク | AI が分割し続けて木が数百に膨れ、人が読めなくなった時点で管理として死ぬ | マイルストーン → タスク → サブタスクの3 層に収める。作業中に見つかった別件が、元のタスクの完了を塞がない台帳にする |
| スケジュール | AI のタスクは数分〜数時間で終わるので、ガントのバーが全部同じ日に潰れる | 日付を持つのはマイルストーンだけ。進捗は人が入力せず完了件数から機械的に出す |
| バグ | 「直したつもり」が積み上がる。修正した本人の判断（なぜそう直したか）が残らない | 「修正した」と「再現しないことを確認した」を別の状態にする。完了は後者だけ |
| バックログ | 「◯◯が出たら再開」と書いた件が、出た後も沈み続ける。思い出せなかったことが原因なので、努力では消えない | 棚上げの理由を「何が成立したら失効するか」の形で構造に持つ。基盤の側から定期的に問う |
これらは AI が賢くなれば解ける類の問題ではありません。
誰も覚えていなくても守られる形——つまり機構になっているかどうかで決まります。
全体は、ひとつの輪でできています
ORQELD の中心にあるのは、4 つの工程を回し続ける輪です。 正本はあなたの git リポジトリにあり、基盤はそれを読むだけで、書き戻しません。
③選定だけ色を変えているのは、ここが「AI に任せると不透明になる」の中心だからです。 着手できるかどうかは、台帳の構造から機械的に決まります—— 依存が終わっているか、棚上げの根拠が失効していないか、由来があるか。 判定の根拠は構造化された記録として残り、後から追えます。
要件と仕様——「どこから出てきたか」を必須にする
タスク管理の道具はいくらでもあります。足りないのは、 そこに載っている作業が「いまの仕様から出てきた物」であることを、誰も保証していないことです。 仕様が変わったとき、該当する作業を探して直すか畳むかは、いまのところ人の記憶に依存しています。
実際に、着手する前に止まった例
当社の既存の作業リストを、この形へ移そうとしたときの話です。 ある 1 件について由来を書こうとしたところ、 参照先として書かれていた画面上のカウンターが、仕様の正本のどこにも存在しませんでした。
由来が任意なら、この作業はそのまま載り、いつか誰かが着手して 「何を作ればいいのか分からない」ところで初めて気づいたはずです。 書こうとした瞬間に露見したので、着手する前に分かりました。
このとき正しい対処は「由来をでっち上げる」ことではありません。選べるのは ①先に仕様を書く（本当に要るなら）か ②その作業を畳む（要らないなら）の 2 つです。 どちらも人の判断で、機械は問うだけです。
仕様は「読み直さなくていい窓」にする
正本になる仕様は二層です。全体構成を示す基本設計と、 外から見た振る舞い（API・画面・失敗したときの見え方）を機能ごとに 1 枚で書く機能設計。 各ファイルには実装状況の表が必須で、「実装だけ変わって仕様が置き去り」の状態——ドリフト——に名前を付けて管理します。
索引を引く道具は、問いに対して関連しそうな文書を数件返します。読んで判断するのは人です。 ORQELD で設計しているのは、値そのものと、出典と、確度を返す問い合わせです。
| 返ってくるもの | 中身 | なぜそうするか |
|---|---|---|
| 値・現在地 | いまの決定内容 | 読み直しを要らなくするため。関連文書を返すだけでは監督コストが残る |
| 出典 | 正本のどのファイルの、どの節か | 本文ではなく出典を持つので、正本はあなたの git のままでよい |
| 確度 | 確定 ／ 暫定 ／ 不明 の 3 値 | 暫定を確定として扱わせないため |
| 決定の時点 | 誰が、いつ決めたか | 「決めたはず」「言ったはず」を消すため。決定は文書に、日付つきで残る |
| 却下された案 | その案は既に見送られた、という記録と理由 | 同じ提案が何度も出てくるのを止める |
| 後からの訂正 | 一度答えた内容が覆ったら、答えた相手へ訂正が届く | 問い合わせは購読でもある。古い前提のまま走り続けるのを防ぐ |
ここで一番大事なのは、台帳に無いことを機械が作らないことです。 該当が無ければ「不明」を返し、そもそもモデルに通さない——そう決めています。 要約もさせません（言い換えた時点でずれの発生源になります）。裁定もさせません（判断は人です）。
タスク・バグ・日程——AI が起票する前提で作り直す
タスク：木の深さを、構造で止める
人が手で作る前提なら、タスクの木は自然に浅く収まります。 ところがタスクを増やすのは AIです。「分割せよ」と言えば分割し続けます。 深さが自由だと木は数百に膨れ、人が読めなくなった時点でタスク管理として死にます。 だから層の数はあらかじめ決めてあります。
| 層 | 誰が作るか | 粒度 | 日付 |
|---|---|---|---|
| マイルストーン | 人 | 週〜月。日程表の行になる | 持つ |
| タスク | 人 | 「こんなことをしなきゃな」と書く単位。AI が受け取る入口 | 持たない |
| サブタスク | AI | AI が分割した実作業 1 件 | 持たない |
そのうえで、作業の途中で見つかった別件が、元のタスクの完了を塞がないようにしています。 「認証を実装する」の途中で見つけた「ログ出力が汚い」を同じ木にぶら下げると、 ログを直すまで認証タスクが完了になりません。これは実運用で必ず起きます。 ORQELD の台帳は、これが起きない形で作られています。
バグ：「直した」と「再現しないことを確認した」は別
バグをタスクと同じ台帳で扱わないのは、大きさが違うからではありません。 完了の意味が違うからです。
| 完了の意味 | 必要なもの | |
|---|---|---|
| タスク | 実装した | — |
| バグ | 修正が入り、再現しないことを確認した | 修正の状態にはコミットの参照が必須／確認の状態には確認した人が必須 |
統合すると、この「確認」の工程が状態から落ちます。 落ちたバグ管理は「直したつもり」を積み上げるだけになり、機能として無価値になります。 修正した本人が自分で確認することは禁止しませんが（止めると運用が回らないので）、 その事実は記録に残ります。
もうひとつ、AI が起票する前提だからこそ必要になる仕掛けがあります。
- 重複を潰す——現象・発生箇所・例外の型から指紋を作り、近いものを提示します。 ただし自動では統合しません。似て非なるバグを自動で束ねると、片方が永久に見えなくなります。
- 「修正内容」と「修正方法」を別の欄にする——前者は差分を見れば分かります。 後者は判断なので、差分を見ても分かりません。半年後に効くのは後者だけです。
- コミットの参照は配列で持つ——1 つのバグの修正が 1 コミットで収まることは稀で、 実装のリポと仕様のリポにまたがることもあります。
スケジュール：進捗率を人に入力させない
| 人手の開発 | AI を使う開発 | |
|---|---|---|
| タスクの長さ | 数日〜数週間 | 数分〜数時間 |
| 起票と完了 | 別の日 | 同じ日に起きる |
| 日程表に引くと | 意味のある線になる | ほぼ全部のバーが同日に潰れる |
だから日付を持つのはマイルストーンだけにしています。 バーの塗り（進捗）は、配下の完了件数から機械的に出します。 人が入力する進捗率は持ちません——入力された進捗率は必ず楽観側に寄り、しかも誰も更新しなくなるからです。 期限を過ぎた行は赤くなりますが、日程を自動で動かすことはしません（動かすと遅れが消えます）。
生産性は「完了」だけでなく「発生」も並べて出します。 完了だけを見ていると、AI が派生タスクを大量に生んでいる状態が「よく進んでいる」に見えます。 発生が完了を上回り続けていることが見えなければ、収束していない仕事を早く捕まえられません。
そして、何を 1 件と数えたかを必ず言えるようにしています。 親のタスクは入れ物なので数えません。取りやめは発生に数え、完了に数えません。重複はどちらにも数えません。 この定義文は画面に直接書かず、集計した側が返した定義をそのまま表示します——2 か所に書くと必ずずれるからです。
作業の記録にはそれが人の操作か AI の操作かが必ず入ります。 だから発生も完了も、人と AI に割って出せます。
バックログ——「答えれば静かになる」形にする
ここが、他のタスク管理と最も差がつく部分です。
「◯◯のサービスが出たら再開」と書いて棚上げした件が、出た後も沈み続ける。 前提にしていた別の作業が「やらないこと」に決まって、残った件がどこからも見えなくなる。 ——どちらも「思い出せなかった」ことが原因なので、努力では消えません。
基盤が問うのは、次の 3 つの場面だけです。期限を切らず、催促もしません。
| 場面 | 問いの中身 |
|---|---|
| 動いていない | 「最後の報告から動いていません。いま『畳む』か『再開する』かを選んでください。 どちらも選ばないまま置くと、他の作業の順番がこれに押さえられ続けます」 |
| 棚上げの条件 | 「〈条件〉はまだ成立していませんか。成立していれば、いま『再開する』を押してください。 まだなら何もしなくて構いません（次の回にまた聞きます）」 |
| 前提が消えた | 「この件の前提は、やらないことになりました。『畳む』か『依存を外す』かを選んでください。 どちらも選ばないと、この件は候補に出てきません」 |
そして、あなたが「畳む」と答えても、基盤は正本を書き換えません。 返ってくるのは「正本をこう直してください」という指示です。 基盤が代わりに書くと、次の同期で黙って元に戻ります——畳んだつもりの件が復活する、という一番たちの悪い壊れ方です。
そして畳んだ件も、消さずに残します。 「やった」だけでなく「やらないと決めた」が記録に残るから、実績の集計が後から正しく出ます （前の節のとおり、取りやめは発生に数え、完了には数えません）。 バックログは願望の置き場ではなく、由来と決定の残る、仕事の入口です。
原本は、あなたの git に残ります
作業項目の正本は、あなたのリポジトリにある Markdown です。 基盤側にあるのは、検索と依存の追跡のための引き写しにすぎません。
| 結果として何が起きるか | |
|---|---|
| やめても資産が残る | ORQELD の利用をやめても、作業項目も仕様も全部あなたの git に残ります。閲覧しか許さない画面に閉じ込めません |
| 履歴が 1 本になる | 「仕様が変わったコミット」と「作業項目が変わったコミット」が同じ履歴に並びます |
| 外に出さない | 原本を自分側に置いたまま運用できる設計です。基盤が持つのは出典と索引で、本文ではありません |
ついでに、机の前にいる必要もなくなります
仕事の状態は手元ではなく基盤側にあり、PC も携帯も、同じ状態をのぞく窓にすぎません。 移動中に声でひと言 → 着く頃に結果。夜に方針だけ渡す → 朝に差分を確認。 こうすると、あなたの返事待ちで AI 群が止まっていた時間が、そのまま回収されます。 指示は打っても話しても通ります。
1 人から、チームへ、企業へ——どこまで確かめられているか
いま毎日動いているのは段階 1です。1 人の統括者が AI の群れを指揮する形で、 統括者は全部を読みません。AI 同士が直接、問い合わせと受け渡しをやり、 決着しない件だけが判断として人に届きます。 段階 2・3 は設計はありますが、まだ自分たちで確かめていません。
段階 1 ── 1 人 ＋ AI の群れ
AI 同士の連絡、計算資源の貸し借り、人への差し戻しを、確度と期限つきで管理します。暴走は世代管理で必ず止まります。
実運用中（当社で毎日）
段階 2 ── チーム
担当者をまたぐ確度つきの照会、一度下した判断の再利用、判断が覆ったときの遡及訂正。
設計あり・複数人での運用は未検証
段階 3 ── 企業
案件の境界（何を見せ、何を見せないか）と、組織単位での実績集計。
設計のみ・未実装
いまの提供状況
| 提供 | 一般提供はまだ始まっていません。実装が進行中で、 利用環境をどう払い出すかも、まだ決めていません（払い出し済みの環境は 0 件です）。 このページに申込やダウンロードの導線を置いていないのは、そのためです |
|---|---|
| 想定する相手 | AI を使って開発しているが、管理と収束のほうで詰まっているチーム・個人 |
| 進め方（想定） | いまの git を正本にしたまま、ひとつの輪を並走させる。道具を一斉に入れ替えません |
| 成功の定義 | 手戻り・放置・検証漏れ・未決の滞留が減ること |
始めるときも、いまの開発環境を捨てさせません。ひとつのプロジェクトを選んで、そこだけ輪をつなぎます。
- いまのリポジトリを、そのまま正本にする——要件や仕様を専用の形式へ移し替えません。いまの git と履歴を残したまま始めます。
- ひとつの成果を選ぶ——ひとつのリリース、あるいはマイルストーンを選び、要件から検証までの線がつながるかを見ます。
- AI に 1 サイクル任せる——同期、集約、着手できる作業の判定、着手前後の報告、判断の差し戻しを、実案件で回します。
- 成果で続けるかを決める——下の指標を、いまの運用と比べます。
見るのは、AI をどれだけ使ったかではありません。
仕様から外れた作業・手戻り・検証漏れ・放置・未決の滞留が減り、同じ人数で仕事が収束したかです。
正直な話
検討していただく前に、こちらの弱いところと、書かないことを先に出しておきます。
-
いま動いているのは、輪の一部です。
AI 同士が人を介さずに調整し、資源を取り合わず、暴走が必ず止まる部分は実運用しています。 作業項目の輪（同期・集約・選定・出力）は実装が進行中で、まだ本番に入っていません。 タスク・バグ・日程の画面は設計は確定していますが、これからです。 どこまで出来ているかを、提供の段階で必ず明示します。
-
一般提供は始まっていません。
利用環境の払い出し方式も未確定で、払い出し済みの環境は 0 件です。 ここに「今すぐ使えます」と書かないのは、書けないからです。開始の時期はまだ申し上げられません。
-
第三者への導入実績は、ありません。
ここに出している数字はすべて当社の自社利用での実測です。 他社の環境で同じ数字が出る保証はしません。
-
特許は、出願しただけです。
2026 年 8 月に出願していますが、登録されるかどうかは、まだ分かりません。 出願中であることを、実装が済んでいることの証拠として読まないでください。
-
要件や仕様を、AI が書いてくれるわけではありません。
ORQELD がやるのは「由来を持たない仕事を走らせない」「不明を不明と返す」「着手できる仕事とその根拠を出す」—— つまり逆向きの解き方です。AI が担うのは 不足の指摘・候補の整理・依存の確認・順番の提案までで、 影響の大きい判断は人へ戻し、誰が決めたかを残します。決めるのは最後まで人で、機械は問うだけです。 「AI が全部やります」と書けるなら書きますが、それは嘘になります。
-
お使いの環境にそのまま入る、とは書きません。
「お使いのエディタにそのまま入ります」とは書きません。確認していないことは書かない方針です。 既存ツールとの接続範囲は、提供の段階で確定します。
よくある質問
Jira や GitHub Issues を置き換えるものですか
単純な置き換えではありません。 そこに載っている作業が「いまの仕様から出てきた物」であることを、 いまお使いの道具は保証していません。保証していないので、仕様が変わったときに 「該当する作業を探して直す／畳む」を人が思い出してやることになります。 ORQELD は由来を必須にすることで、これを機械的に洗い出せる状態に変えます。 逆に言えば、それ以外の点では既存の道具のほうが機能は豊富です。 既存ツールとの接続範囲は、提供の段階で確定します。
AI に仕様を管理させて、平気なんですか
「答える力」を推論の側に置いていないからです。 問い合わせのときにやるのは該当項目を選ぶ・そのまま転記する・確度と出典を添えるだけで、 台帳に無ければ機械が「不明」を返します（モデルに通しません）。 要約もしません——言い換えた時点でずれの発生源になるので、原文を引きます。 裁定もしません——判断は人です。
現在地：この問い合わせの仕組みは設計まで済んでいますが、実装はこれからです （上の「要件と仕様」の現在地と同じです）。
AI を大量に並べたら、収拾がつかなくなりませんか
そこが最初に作った部分です。計算資源は共有の台帳を通してしか掴めず、 暴走の連鎖は世代の数え上げで必ず止まります。 同一ファイルへの黙った上書きは、書き込みを順番待ちで直列化して—— 唯一の書き手を置き、他は依頼を出すだけにして——機構で止める設計です。 これらは規律（ルール文書）では解けませんでした—— ルールを読んでいない参加者が壊し、ルールを書いた本人も次の場面では見ないからです。
現在地：資源の台帳と世代の数え上げは当社で毎日動いています。 書き込みの直列化は設計まで済んでいますが、実装はこれからです。 事故がどれだけ減ったかの集計もまだ出していません（個別の事象は記録に残っています）。
テストケースも AI が作ってくれますか
専用のテスト管理機能はありません。これは無いのではなく、作らないという判断です。 テストはコードと同じリポジトリで AI が書き、AI が実行します。 管理層にテストの写しを作ると、コードとテストのずれの上に、さらに管理表とのずれが積み上がるだけ—— 二重管理を作らないのも設計判断のうちです。
そのうえで ORQELD が持っているのは、テストの組み方の規律のほうです—— 実装と監査を別々の AI で 2 段に回して指摘を全部閉じるまで取り込まない、 守り 1 つにつきテストを 1 本持つ（1 本のテストが 2 つの守りを同時に踏むと、互いに隠して素通りします）、 全部ゼロでも成立してしまう検査を書かない。 いずれも当社の開発で実際に事故ってから固めたものです。
ソースコードや社内の仕様書を、外に出すことになりませんか
なりません。正本はあなたの git のままで、基盤が持つのは出典と索引です。 むしろ「外に出せない社内の知識を扱う」ことが前提の設計です。 どこで動かすか（設置の形態）は、提供の段階で確定します。
いつから使えますか
一般提供はまだ始まっていません。 利用環境をどう払い出すかも決まっておらず、払い出し済みの環境は 0 件です。 開始の時期・方法が決まりましたら、このページで公開します。 いまお伝えできるのは、何が動いていて、何がこれからかまでです（上の「正直な話」）。
AI が賢くなっても、要件・仕様・テスト・タスク・日程・バグ・棚上げは自動では揃いません。
揃わない限り、成果は出た「はず」のまま止まります。
人が決める。AI が動く。