「AIを使って作りました」という一文は、読み手にほとんど何も渡しません。どこまでをAIが書き、どこからを人が決めたのかが、その一文からは復元できないからです。本稿は、実在するWebツール──株式の理論株価を複数の評価手法で算出して並べる分析ツール──の開発を題材に、AIと人間の協働を「確認できたこと」と「まだ言えないこと」に分けて記録します。先に書いておくと、この題材で量が多いのは後者です。

対象は、AIを使って自社のツールやページを作り、その公開を承認する立場の方です。本稿は投資判断の記事ではありません。個別銘柄の評価、売買の推奨や示唆、理論株価という考え方の当否、算出手法の優劣は扱いません。AIコーディングの一般的な工程はAIコーディング支援でWebページを作る工程と限界、主張を一次情報へ照合する一般手順は生成AIの出力をファクトチェックする実務手順、試験から本番へ移す受入条件は生成AI PoCの設計──本番移行を判断する受入条件で扱っています。本稿はそれらを再説明せず、一つの実例で「何を証拠として言えるか」に絞ります。

1. Lab記事として何を記録するか

Lab は、一般論の整理ではなく、実際に手を動かした記録を置く場所です。題材にするのは、株式会社トリロジーが公開している理論株価分析ツールと、その運用状況を集計するフォワードシミュレーションのページです。

先に断っておくべきことがあります。本稿の発行者と、題材にするツールの公開主体は同じです。自社の事例を自社の媒体で書く位置にいる以上、良く見せる方向へ寄る動機が働きます。それを打ち消す手立ては、書き手の誠実さを宣言することではなく、読者が同じ材料に当たれる形で根拠を示し、当たれないものは当たれないと書くことだと考えています。

記録するのは、公開ページから誰でも読める表示、開発の履歴から取れる限定的な事実、そしてそこから言えないことの三つです。逆に、次のものは扱いません。

  • 個別銘柄の評価、推奨、勧誘、売買判断の示唆
  • 手法の計算式、パラメータ、内部の計算ロジック、会員向け表示の逐語
  • 会員限定の結果、銘柄名、価格、認証や配信の実装
  • 投資助言該当性、法令適合、公開許諾といった法的な結論

本稿の最大の制約

本稿の準備段階で、開発の経緯について確かめたい事項を13問に整理しました。執筆時点で、その回答は得られていません。そのため本稿には、「なぜ10手法なのか」「なぜ一つに統合しないのか」「なぜバックテストではなくフォワードなのか」「誰が何を決めたのか」という判断の理由が一つも書かれていません。公開ページから読み取れるのは結果としてどうなっているかであって、なぜそう決めたかではないためです。

この空欄を一般論で埋めることはしません。埋めれば読みやすくはなりますが、その瞬間に本稿は「確認できたことの記録」ではなくなります。

2. 公開されているツールの輪郭

以下は、2026年8月26日に確認した現行の公開ページ上の表示です。表示は改定されうるため、確認日と併せて読んでください。掲げられている手法は、DCF法、配当割引モデル（DDM）、純資産法、残余利益モデル（RIM）、PER相対法、PBR相対法、収益還元法、EBITDA相対法、PSR相対法、PCFR相対法の10種類です。

算出結果の位置づけについて、ページは次のように表示しています。

  • 「本ツールが算出する理論株価は、複数の評価モデルに基づく参考値です。」
  • 「単一の「正しい株価」を示すものではなく、手法ごとに複数の見方があります。」
  • 手法について「それぞれに適用限界があります」
  • 「算出結果は特定銘柄の売買を推奨・勧誘するものではありません。」
  • 「市場価格と理論株価は乖離することがあり、市場が常に正しいとは限りません。」

表示の意味の範囲も限定されています。「各カードの枠色（赤：理論株価が現在株価を上回る／青：下回る）は、大小関係を事実として示すものであり、売買の推奨・示唆ではありません。」

もう一つ、別ページとしてフォワードシミュレーションの集計が公開されています。過去へ遡らず開始日以降だけを記録する設計で、これは節7で扱います。

表示があることの意味の範囲

これらの表示が置かれていることは、本稿が確認できた事実です。一方で、表示があることは、算出結果が妥当であることや、ツールの提供が法令上どう位置づけられるかを示すものではありません。本稿は前者を記録し、後者について結論を出しません。

3. 協働開発を何で確認するか

「AIと人間で作った」と書くとき、書き手は性質の違う材料を一つの文へ流し込んでいます。出所も利用条件も異なる材料を混同すると、どの主張を何が支えているのかと、その材料をどこまで使ってよいのかが、どちらも不明瞭になります。そこで本稿では、材料を五つの区分に分け、区分ごとに「記事の主張として使うために満たす条件」を先に決めました。

協働開発の根拠を、公開ページ・限定記録・二次記録・未確認・使用禁止の五つに分けた図。各区分の内容は図の直後の一覧に記載。
図：協働開発の根拠を、出所と利用条件の違いで五つに分け、それぞれに記事の主張として使うための条件を置く。この分け方は本記事による編集上の整理である
  • 1 公開ページ：誰でも同じ画面に当たれる表示。条件は、URLと確認日を添え、逐語で引くこと。本稿の主要な根拠はこの区分です
  • 2 開発履歴から取れる限定記録：コミットの日付、変更のおおまかな単位、トレーラーの有無など。条件は、読み取れる範囲を超えないこと。何が起きたかの輪郭は取れますが、なぜそうしたかは取れません
  • 3 二次記録：開発の経緯をあとから整理した内部資料や要約。条件は、誰が確認したと記録しているかを同じ文に書くこと。本稿が独立に確かめ直したものではありません
  • 4 未確認：13件の確認事項への回答、実ブラウザでの通し確認。条件は満たされていません。未確認として書くか、書かないかの二択です
  • 5 使用禁止：会員限定の結果、銘柄名、価格、認証や配信の詳細、内部の計算ロジック。条件の問題ではなく、扱わないと決めた範囲です

各区分に併記したのは、その区分の材料を記事の主張として使うために満たす条件です（広い画面では区分名の右、狭い画面では区分名の下）。条件を満たさない材料を、満たしたことにして別の区分の扱いへ移すことはせず、主張を削るか、未確認として残します。

五つの区分は、出所と利用条件の違いで分けたものです。上ほど強いという一本の序列ではありません。どの材料が強いかは、支えようとしている主張との対応で決まります。「この文がページに表示されている」であれば公開ページが直接の証拠ですが、「いつ何を変更したか」であれば開発の履歴のほうが直接的です。5の「使用禁止」も弱い証拠ではなく、扱わないと決めた区分です。図に矢印を置いていないのは、五つが工程でも序列でもないからです。

この分け方が効くのは、書くときではなく削るときです。区分と条件を先に決めておくと、「面白いが裏づけの取れない話」を落とす判断が、書き手の気分ではなく条件の当てはめになります。

4. Co-authored-by から言えること／言えないこと

AIとの協働を数字で示したくなったとき、手近にあるのがコミットメッセージのトレーラーです。Co-authored-by という行を加えると、そのコミットに複数の作者を紐づけられます。まず、仕様を定めている側の説明を確認します。

GitHub Docs は次のように書いています。「Add one or more Co-authored-by trailers to a commit message to attribute a commit to multiple authors.」（コミットを複数の作者に帰属させるため、コミットメッセージに1つ以上の Co-authored-by トレーラーを追加する）。さらに「For the commit to count as a contribution, use an email address associated with their account on GitHub.com.」（そのコミットが貢献として数えられるためには、GitHub.com のアカウントに紐づくメールアドレスを使う）とも示しています。

読み取れるのは二つです。この仕組みは作者の帰属を記録するものであること。そして、そのコミットがGitHub.com 上で貢献として数えられるためには、アカウントに関連づいたメールアドレスを使う必要があること。後者は帰属そのものの成立条件ではなく、貢献としての計上に関する条件です。この文書の本文は、生成AIに触れていません。

件数についても同じ注意が要ります。本稿の題材では、AIが整理した内部資料の作成者が、2026年8月7日の初回実装から同月25日までのコミットの一部にこのトレーラーが含まれていたと確認して記録しています。ただし本稿は、元のコミット集合を独立に数え直していません。そのため件数そのものを本文では使いません。仮に件数が分かっていたとしても、そこからAIが書いた量の割合を示す主張は導けません。トレーラーはコミット単位の帰属であって、行数でも工数でもないためです。

トレーラーから言えること言えないこと
そのコミットに、追加の作者が帰属されているその内容を誰がどれだけ書いたか
GitHub.com上で貢献として数えられるための、メールアドレスの条件作業時間、費用、生産性
トレーラーを含むコミットを数える対象にできるコード量に占める割合
記録が残っている範囲を示せる設計や採否を誰が決めたか
—トレーラーがないコミットでAIを使わなかったこと

最後の行は反対向きの誤読です。トレーラーは書き手が付けるものなので、付いていないことは記録がないという事実を示すにとどまります。「AIが多い」も「人間が多い」も、この材料からは同じ理由で言えません。

5. 人が持ち続ける判断の境界

ここは、本稿がいちばん書けない節です。誰がどの工程を担い、どの案が採られ、どれが却下されたのか──その回答が得られていません。ですから本稿は、この題材における実際の分担を報告しません。

作る・確認する・決めるをどう割り当てるかという一般原則はAIと人間の役割分担をどう決めるかで扱っています。本稿が分担の中身の代わりに引くのは、本稿自身の運用境界——記事を書くうえで人側に残すと決めた三つ——だけです。

  • 公開の境界：どこまでを誰でも見られる状態にし、どこから先を出さないか
  • 採否：出てきた案を採るか採らないか。採らなかった案は成果物に残らないため、記録しなければ後から辿れません
  • 法的な位置づけ：その提供が法令上どう扱われるかの判断。本稿はこの判断を行わず、結論も書きません

これは網羅ではなく、本稿が引いた線です。そのうえで、実例から出てきた一点を付け足せます。

「人が決めた」と書けるかどうかは、人の関与の有無ではなくその決定が記録に残っているかどうかにかかっています。決めた事実があっても、記録がなければ、後から確かめられるのは成果物の形にとどまります。本稿がこの節を短く終えるのは、まさにその状態にあるからです。

6. 複数手法を一つの答えへ統合しない設計

公開ページに10の手法が並んでいるとき、素朴な疑問は「結局どれが正しいのか」です。これに一つの数字で答える作り方はあり得ますが、このツールはそうしていません。節2で引いたとおり、ページは単一の正しい株価を示すものではないと述べ、手法について「それぞれに適用限界があります」と書いています。前提の異なる複数の値を一つへ丸めると、丸めたあとの数字からはどの前提が効いているかが見えなくなります。

ただし──ここが本稿の制約です──この設計を選んだ理由は、本稿では確かめられていません。公開ページから読めるのは「結果としてこうなっている」であり、判断の経緯ではありません。次の図も、結果としての構造を並べたものです。

前提の異なる複数手法を一つの正解へ統合せず、開始日以降の観測へつなぐ構造を上から順に示した図。各段の内容は図の直後の一覧に記載。
図：前提の異なる複数手法を一つの正解へ統合せず、開始日以降の観測へつなぐ構造。公開ページ上の表示から読み取れる並びを本記事が整理したもの
  • 前提の異なる複数の手法：算出の出発点が手法ごとに違う
  • 個別の見方として表示：手法ごとの結果を、それぞれの見方として並べる
  • 一つの正解へ統合しない：合成した単一の数字を「正しい株価」として提示しない
  • 開始日以降を観測：固定した日以降の記録を積み上げる
  • 結果からルールを遡及変更しない：後から見た成績に合わせて過去の条件を書き換えない

図の矢印は、公開ページ上で確認できる構造の並びを上から順に示します。設計者がこの順序で判断したことを示すものではありません。また、統合しない作り方それ自体が結果の妥当性を与えるわけでもありません。言えるのは、読み手が前提の違いを見られる状態が残る、という構造上の性質までです。手法名と一般的な考え方の範囲を超えて、計算式、パラメータ、内部の計算ロジック、会員向けの解説文へは踏み込みません。手法の優劣を論じることも、どの手法を見るべきかを示すこともしません。

7. バックテストではなく、開始日以降の観測

公開ページは「2026-08-14以降のデータのみを記録しており、過去に遡って算出したもの（バックテスト）ではありません。」と明記しています。同じページは、この記録が「実際の売買を伴わない仮想シミュレーション」であることも表示しています。実際の取引ではなく、開始日以降の記録を積み上げた仮想の記録だ、という二重の限定です。

ページはルールの扱いについても「売買ルールは2026-08-14に固定したもので、その後の成績を見て有利になるよう変更することはありません。」と書き、さらに「変更する場合は、変更日・変更内容・変更理由をこのページに記録します。」としています。

同時に、この記録が何でないかも同じページに示されています。

  • 「勝ちトレード・負けトレードの両方を、選別せずすべて記録・表示しています。」
  • 「手数料・税金・スリッページは考慮していません。」および「資金制約は考慮していません」
  • 「当該算出手法自体に前提や偏りがある場合、その影響は本シミュレーションの結果にも及びます。」──物差しの側に偏りがあれば、測った結果にも入り込みます
  • 「算出手法の正確性・優位性を保証するものではありません」および「将来の運用成果を示唆・保証するものではなく」

本稿は、このページに載っている数値（平均リターン、決済件数、勝率、保有件数）を掲載しません。時間とともに変わる値であり、記事に固定した瞬間に古くなるためです。項目としてページに存在することまでが本稿の確認範囲で、値そのものを主張の材料にはしません。

これは「AI導入の効果測定」ではありません

混同されやすい点なので明示します。この観測が測ろうとしているのは理論株価という物差しの側であって、AIの働きぶりではありません。開発にAIをどう使ったかと、出力された物差しが以後どう振る舞うかは、別の問いです。AI導入の効果をどう測るかという論点は生成AI導入の効果測定──業務成果を測る方法で扱っています。本稿のフォワード観測をその指標として読まないでください。

この観測が示すこと示さないこと
ルールを固定した日付と、変更時の記録方針将来の運用成果
考慮していない条件が明示されていること実際の取引で得られる結果
物差しの偏りが結果へ及ぶという前提の開示特定銘柄についての判断材料

8. 失敗談を記事化する条件

失敗談は、当事者が語れば成立してしまい、外から確かめる材料が残りにくい種類の記録です。本稿には失敗の具体例がありません。書けなかったのではなく、次の三つが揃っていないため置いていません。

  • 証拠：何が起きたかを、記憶や要約ではなく、後から同じものに当たれる記録で示せる
  • 公開可否：その記録を外へ出してよいかが、権限を持つ人の判断として確定している
  • 残る限界：修正したあとに何が確かめられていないかを、同じ場所に書ける

三つ目を落とすと、失敗談は「問題が起きた→直した→解決した」という形に整います。直したあとに何を確かめていないかが抜けたまま、解決として記録されます。

裏づけと限界を欠いた失敗談は、向きが違うだけで成功譚と同じ種類の宣伝になります。本稿がこの節を条件だけで終えるのは、条件を満たす材料が手元にないためです。

9. 公開後も確かめ続ける

引用した表示は改定され、集計は更新されます。ずれを承知のうえで、何をいつ確かめ直すかを先に決めておきます。

確かめる対象いつ確かめられること確かめられないこと
引用した公開ページの表示公開の直前と以後の見直し時逐語が現行の表示と一致するか今後も同じ表示が続くか
ルール変更の履歴同上変更の記録がページに現れているか記録の方針が将来どう運用されるか
実ブラウザでの通し確認公開の前後実際の画面で表示と導線が成立するかあらゆる環境での挙動
既存ページへの影響公開の前後公開前から在るページの表示が変わっていないか—

三つ目を独立して置くのは、ビルドが通ることと、画面で成立していることが別だからです。本稿の題材でも、実ブラウザでの通し確認は実施済みの記録を確認できていない項目として残っています。

10. 読者が転用できる記録表

ここまでの分け方を、そのまま使える形に畳みます。「AIと作った」と書きたくなったとき、書く前にこの8欄を埋めます。埋まらない欄が、その時点で書けないことです。

欄書く内容本稿での記入
claim（主張）外へ出す一文公開ページは10の評価手法を掲げ、単一の正しい株価を示すものではないと表示している
evidence（根拠）出どころと確認日現行の公開ページ（2026年8月26日確認）の逐語
actor（確認者）誰が確認したか本稿の編集側。開発当事者の確認ではない
decision（決定）誰が何を決めたか空欄。回答が得られていない
verification（再確認）どう確かめ直すか同じURLを再取得し、逐語と確認日を照合する
unknown（未確認）分かっていないこと手法数、統合しない設計、フォワードを選んだ理由、役割分担、失敗の具体例
prohibited（不記載）出さないと決めたもの会員限定の結果、銘柄名、価格、認証や配信の詳細、内部の計算ロジック
next check（次の確認）次にいつ何を見るか公開の直前に両ページの表示とルール変更の履歴を再確認する

この8欄は本記事による編集上の整理です

公的な規格でも、題材ツールの開発側が定めた分類でもありません。自社の記録の形に合わせて欄の名前や粒度を組み替えてください。要点は欄の名前ではなく、claim と evidence を別の欄に置くこと、そしてunknown 欄を消さないことにあります。

この表を先に埋めると、原稿の分量が減ることがあります。減った分は失われたのではなく、根拠のない部分が可視化されただけです。

まとめ

本稿は、AI協働開発の事例記事として読めば物足りない記事です。誰が何を決めたかが書かれておらず、設計の理由もなく、失敗談も入っていません。それは題材が薄いからではなく、確認できていないものを書かないと決めたからです。

残ったのは、公開ページから逐語で引ける表示、仕様書から読み取れるトレーラーの意味、性格を明示した二次記録が1件、そして未確認として並べた項目です。この配分自体が、本稿の主題の答えになっています。AI協働開発の説明責任は、AIの関与を大きく見せることではなく、何を確認でき、誰が何を決め、何をまだ言えないかを、証拠とともに分けることで成立します。

成果物が増える速さと、根拠が揃う速さは別です。二つを揃えて語ると、AI活用の話は成果の約束へすり替わります。本稿が最後まで避けたのはその一点です。

手元でこの型を試すなら、直近にAIと作った成果物を一つ選び、節10の8欄を埋めてみてください。最初に埋まらないのが decision 欄なら、それは記録の設計が足りていないという現在地です。

引用元・参考文献

公式ドキュメント

題材とした公開ページ

  • 株式会社トリロジー『理論株価分析ツール』（10の評価手法、参考値である旨、単一の正しい株価ではない旨、適用限界、枠色の意味、売買の推奨・勧誘ではない旨／確認日：2026年8月26日）：https://dividend.trgy.co.jp/
  • 株式会社トリロジー『理論株価フォワードシミュレーション』（記録開始日、バックテストではない旨、選別しない全件記録・表示、ルールの固定と変更時の記録方針、考慮していない条件、非保証の表示／確認日：2026年8月26日）：https://dividend.trgy.co.jp/simulation/

※ 証拠の五区分、図1・図2の並び、記録表の8欄は本記事による編集上の整理であり、公的な規格でも、題材ツールの開発側が定めた分類でもありません。本文で触れたコミットのトレーラー記録は、AIが整理した内部資料の作成者が確認したと記録した二次情報であり、本稿は元のコミット集合を独立に数え直していないため、件数そのものを本文では使っていません。GitHub Docs は生成AIについて述べておらず、トレーラーの記録を生成割合や工数の根拠として扱うことはできません。本稿は、開発の経緯について整理した13件の確認事項に回答が得られていない状態で作成しています。公開ページの表示および集計は改定・更新されるため、参照時は最新の表示をご確認ください。