プログラムレベルと圏論の用語の対応がよくわからなかったのでチャッピーに教えてもらったので備忘録
Hask は「型と関数」からなる圏。
Maybe は Hask から Hask への自己関手。
Just は、恒等関手 Id から Maybe 関手への自然変換。
bind は、Maybe モナドの合成操作で、join という自然変換を使って作られる。
生成AI時代の業務アプリ開発メソッド
Agent前提 ITシステム開発メソッド
1. このメソッドの考え方
このメソッドは、企業向け業務アプリケーション開発をAgent前提で再設計するためのものである。対象は、受発注・在庫・会計・人事のように、明確なビジネスルールに従って動くシステムである。
前提は次の通り。
- Agentが成果物の生成と変換を担う
- 人間が業務ルールの定義・判断・確認・責任を担う
- 品質の起点はコードではなく業務ルールの正しさにある
このメソッドが重視するのは、認知ギャップの管理である。認知ギャップとは、人間が意図した内容とAgentが解釈・実装した内容のズレを指す。これをなくすことは難しいが、起きやすい場所を絞り、検知できる形にすることはできる。
2. 基本原則
認知ギャップは管理する
ズレをゼロにすることではなく、どこに閉じ込めてどう検知するかを設計する。
人間の確認は高抽象度に集中する
人間は業務意図、ドメインモデルの意味確認、構造判断、高リスク変更を確認する。
アーキテクチャが確認面積を決める
制約が強いほど、問題が起きる場所を予測しやすくなり、レビュー範囲を狭められる。
3. 用語の整理
業務モデル
何を実現するかを業務の視点で表したもの。ユースケース、ドメインモデル、アプリケーションサービス、ビジネスルールで構成する。
ドメインモデル
業務モデルの中核。エンティティ、値オブジェクト、集約、ドメインサービスとその制約を表す。人間はデータ構造・実際のデータイメージ・ビジネスルールの記載が業務意図に合っているかを確認する（意味確認）。実装の妥当性はコード読解ではなくコンポーネント単位の機能テストで確認する。
ビジネスルール
業務上の決まりごと。制約ルール（WHEN-THEN・ONLY IF・不変条件）と派生ルール（IF-THEN・計算）の2種に分類する。
サービス仕様
コンポーネントのインターフェース・型定義・事前条件・事後条件をまとめたもの。ドメインモデルとビジネスルールからAIが生成する。通常時は合否判定の補助資料として位置づける。ただし高リスク機能では、E2Eテストに加えてサービス単位の機能テスト結果でも確認し、サービス仕様の内容を人間が理解することを推奨する。
高リスク
業務的に正しく動作しなかった場合の影響範囲・深刻度が大きいもの。金銭影響・業務停止・法令/監査影響・顧客影響・重要業務の誤処理などが判断基準となる。レビューや確認対象を選ぶ際の基準として使う。
設計モデル
業務モデルからAIが生成する中間成果物。実装構造や依存関係を表し、トレーサビリティの証跡として保持する。
アーキタイプ
システム内で繰り返し現れる実装単位の種類。ドメインモデル・アプリケーションサービス・インフラ・UIなど。アーキタイプごとにリスクと確認戦略が異なる。
確認面積
人間が確認しなければならない範囲の広さ。
4. 開発の流れ
開発はイテレーション型で進める。各イテレーションで次の4つを回す。
最初のイテレーションでは、アーキテクチャの骨格と生成AI活用の仕組み（プロンプト・評価セット・生成ガイドライン）を確立する。典型ユースケース1本でサイクルを通し、量産前に整備する。
1. 業務モデル定義
人間がユースケース、ドメインモデル、アプリケーションサービス、ビジネスルールを定義する。ここで業務意図が曖昧なままだと、後続の設計やコード生成も不安定になる。
確認ポイントは次の通り。
- 業務担当者が読んで正しいと言えるか
- 正常系と異常系が定義されているか
- ビジネスルールが制約ルール・派生ルールの型で整理されているか
- 不変条件・操作制約・状態遷移が明示されているか
- 用語の解釈にズレがないか
2. 方式設計
レイヤー構造・モジュール境界・インターフェースを設計し、非機能要件への対応方針を定める。選択肢の列挙・トレードオフ分析・ドラフト生成はAIに担わせ、人間は判断と決定を行う。
Agent前提の開発では、このアーキテクチャ設計がさらに「どこで問題が起きやすいか・どこで人間が確認すべきか」を規定する意味も持つ。
アーキタイプごとにAI適用レベルと確認戦略を定める。
| アーキタイプ | リスク | 確認戦略 |
|---|---|---|
| ドメインモデル | 最高 | データ構造・ビジネスルールの記載が業務意図に合っているかを人間が確認する（意味確認）。実装の妥当性は主にコンポーネント単位の機能テストで確認する |
| アプリケーションサービス | 高 | 通常時はE2Eテストの実行結果で確認。高リスク機能ではE2Eテストに加えてサービス単位の機能テスト結果でも確認し、サービス仕様の内容を人間が理解する |
| インフラ・リポジトリ | 中 | 人間確認は基本省略。機械的検証で担保。問題時はサービス仕様を起点に確認 |
| UI・プレゼンテーション | 低 | 自動テスト＋視覚確認。実装詳細の人間レビューは不要 |
アーキテクチャ制約は、ガイドラインではなくCIで強制する。
認知ギャップの検知を目的として、処理ログの記録・トレース機能を実装し、AIが生成したコードの動きを可視化できる状態にすることを推奨する。可視化によって、業務ルールが意図通りに実行されているかを観測しやすくなり、E2Eテストの実行結果と合わせて認知ギャップの発見精度が上がる。
3. 詳細化・生成
AIが業務モデルからサービス仕様を含む設計モデル・コード・テストを生成する。
確認の区分は次の通り。
常時・人間が確認するもの（意味確認）
ドメインモデルの定義（データ構造・実際のデータイメージ・ビジネスルール）が業務意図に合っているか
高リスク機能では追加で確認するもの
サービス仕様の内容を人間が理解する
原則自動検証に委ねるもの
実装詳細・定型インフラ・UI詳細・コード・テスト（E2Eテスト、機能テスト、単体テスト）
4. 検証
E2Eテストは業務受入確認の主要手段として位置づける。人間は「業務シナリオとして正しいか」を確認し、AIはテストコード生成や静的解析を担う。
通常時の主検証はE2Eテストの実行結果である。高リスク機能ではE2Eテストに加えて、サービス単位の機能テスト結果でも確認する。
| 検証層 | 適用場面 | 位置づけ |
|---|---|---|
| E2Eテスト（業務シナリオ・成功条件・禁止条件・副作用・イベント発行・監査ログ） | 常時 | 主検証（業務受入の主要手段） |
| サービス単位の機能テスト | 高リスク機能（追加） | 追加検証 |
| 単体テスト（複雑なドメインモデルのロジックを重点的に） | — | 補助 |
| 品質・安全性のサンプリング確認 | — | 補助 |
テストシナリオはユースケース・ドメインモデルからAIが生成する。人間はシナリオの網羅性と実行結果を確認する。
5. 成果物体系
成果物は4層で設計する。すべてを同じ密度でレビューしない。
| 層 | 内容 | 確認の扱い |
|---|---|---|
| 定義層 | 業務モデル・アーキテクチャ設計書・検証シナリオ | 常時・人間が確認（ドメインモデル・業務モデルの記述は意味確認） |
| 実行結果層（通常時の主検証） | E2Eテスト結果（業務シナリオ・成功条件・禁止条件・副作用・イベント発行・監査ログ） | 自動実行し・人間が結果を判断（合否判定の主手段） |
| 実行結果層（高リスク機能の追加検証） | サービス単位の機能テスト結果 | E2Eテストに加えて確認。サービス仕様の内容も人間が理解する |
| 補助資料層 | 設計モデル・サービス仕様 | 通常時は補助資料。高リスク機能では内容を人間が理解することを推奨 |
| 実装層 | ソースコード・単体テスト | 原則自動検証 |
6. 改善ループ
改善ループは、イテレーションをまたいで次の2つを見直す活動である。
- 開発プロセスの改善 — プロンプト、評価セット、生成ガイドライン、アーキテクチャ制約の改善
- 業務モデルの是正 — 認知ギャップによって見つかった業務解釈のズレの修正
新規要件や機能追加は改善ループでは扱わず、通常のイテレーション計画で扱う。
7. 役割分担
人間
業務モデラー
業務モデルを定義し、業務モデル・ドメインモデルの記述が業務意図に合っているかを確認する。
アーキテクト
方式設計・アーキタイプ別確認戦略・AI活用ルール・制約をCI強制として設計する。
評価設計者
何をどう検証するかを設計する。検証シナリオの観点（成功条件・禁止条件・副作用・イベント発行・監査ログ）を定義する。
開発者（レビュアー）
ドメインモデルの記述確認（意味確認）、E2Eテスト・機能テストの実行結果確認、高リスク機能でのサービス仕様の内容理解、変更差分を中心に確認する。
AI
あらゆる成果物（業務モデル・設計モデル・サービス仕様・コード・テスト）のドラフト生成
選択肢の提示・トレードオフ分析・設計支援
静的解析、テスト実行、品質傾向の分析
8. このメソッドの要点
このメソッドの要点は3つである。
- 人間は「全部を作る人」ではなく、「何が正しいかを定義し確認する人」になる
- AIは「コードを書く道具」ではなく、「成果物を変換する実行主体」になる
- 品質は、コードレビューの量ではなく、業務モデルの明確さとアーキテクチャ設計・実行結果の検証で決まる
システム開発における生成AI活用と認知ギャップ
システム開発における生成AI活用と認知ギャップについて整理し、活用度が上がるほど拡大する「認知ギャップ」とその対策を解説する。
生成AIの活用を「なんとなく使う」から「意図して制御する」状態に引き上げるための考え方をまとめた。
この記事は4つのテーマで構成する。
- 生成AIの活用レベル — QA〜Operating Modelまで5段階で整理
- 認知ギャップ — 活用レベルが上がると何が「見えなくなる」か
- リスクと活用レベルの対応 — システムのリスク帯ごとの適切な活用レベル
- 実践的な考え方 — 選択原則・対策・判断フロー
1. 生成AIの活用レベル
生成AIの活用は「単なる情報検索」から「業務・組織の再設計」まで、5段階のレベルで整理できる。上位レベルになるほど自律性・業務影響度・リスクが増大し、より高度なガバナンスが求められる。
| レベル | 名称 | AIの役割 | 人の役割 |
|---|---|---|---|
| ① | QA（情報提供） | 情報を返す | 判断する |
| ② | Task（作業実行） | 作業を終わらせる | 結果を確認する |
| ③ | Workflow（手順実行） | 作業の流れを回す | 要所でレビューする |
| ④ | Agent（自律実行） | 状況に応じて進め方を変える | 目的・境界を設定する |
| ⑤ | Operating Model（業務再設計） | 仕事のやり方自体を変える | 判断・責任・例外対応 |
①のQAは検索エンジンの延長として馴染みやすいが、④のAgentになると人間が把握しきれない判断をAIが自律的に行う。⑤のOperating Modelはこの認知ギャップを前提として組織・業務設計に織り込んだ到達点であり、①〜④とは視点が異なる。
2. 認知ギャップとは何か
便利さと「見えなくなること」のトレードオフ
AIの活用レベルが上がるほど、処理量・判断量・スピードが増大する。その結果、人間が全体を追い切れない状態が生まれる。
認知ギャップ ＝ AIがやっていることを、人が正しく理解できていない状態
典型的な症状として以下が挙げられる。
- なぜその答えになったかわからない
- 間違いに気づけない
- 「確認しているつもり」で確認できていない
レベル別の認知ギャップ
| レベル | ギャップの大きさ | 主な見えにくさ |
|---|---|---|
| ① QA | ほぼなし | 回答根拠の深さ |
| ② Task | 小 | 根拠・途中経過は確認しないことが多い |
| ③ Workflow | 中 | ステップ間の中間状態が見えにくい |
| ④ Agent | 大 | 判断の経緯・ツール選択が追えない |
活用レベルが上がるほど、間違いに気づきにくくなる危険度が上がる
特にAgentレベルになると、AIが複数のツールを組み合わせて自律的に動くため、何をどの順番でどう判断したかを人間がリアルタイムで把握することは現実的に難しい。「動いているから大丈夫」という感覚こそが、認知ギャップの落とし穴である。
3. ITシステムにおけるリスク許容度と活用レベルの対応
システムの性質によって、どのレベルまでAIを適用できるかが異なる。リスクが高いシステムほど、AI適用レベルを低く抑え、認知ギャップを意図的に縮小する必要がある。
| リスク帯 | 典型システム | AI適用レベル | 人の役割 | 認知ギャップ | 主なリスク | 運用のポイント |
|---|---|---|---|---|---|---|
| 低 | 社内ツール・検証環境 | Agent | 結果確認中心 | 大 | 中身を理解せず使う | スピード優先、問題が出たら直す |
| 低〜中 | 業務支援ツール | Workflow〜Agent | 要所確認 | 中〜大 | ミスの見逃し・誤動作 | 信頼度で人に戻す |
| 中 | 顧客向けサービス（非金融） | Workflow | 判断＋レビュー | 中 | 誤動作・品質低下 | 人レビュー必須・段階リリース |
| 中〜高 | 基幹システム | Task〜Workflow | 詳細確認＋責任 | 小〜中 | ロジックミス・影響拡大 | テスト重視・制約設計 |
| 高 | 銀行・決済システム | Task（AI補助） | 設計・承認・責任 | 小（抑制） | 金銭事故・監査NG | 人主導・完全トレーサビリティ |
社内ツールや検証環境はミスが許容されやすいためAgentレベルも選択肢に入るが、銀行・決済システムのような高リスク領域ではAIはあくまで補助にとどめ、人間が設計・承認・責任を担う構造が求められる。
4. 実践的な考え方
4-1. AIレベルの選択原則
リスクが高いほど、以下の3軸で対応する。
- ① AI活用レベルを下げる
- ② 認知ギャップを意図的に縮小する
- ③ 人の関与を増やす
この3軸は独立しているように見えるが、実際には連動している。AI活用レベルを下げれば自然と認知ギャップは縮まり、人の関与が増える。重要なのは「なんとなくAgentを使わない」のではなく、リスクに応じて意図的にレベルを選択することである。
4-2. 認知ギャップへの対策
上記3軸に基づく具体的な対策は以下のとおり。
| 対策カテゴリ | 具体的アプローチ |
|---|---|
| 可視化 | 処理ログの記録・トレース機能を実装し、AIの動きを可視化して認知ギャップを縮小する |
| 人の関与点設計 | Workflow中に人間のレビューポイントを明示的に設け、人の関与を増やす |
| スモールスタート | 低リスク領域でAI活用レベルを抑えて試し、パターンを学習してから段階的に適用拡大する |
| 境界設定 | Agentの権限・ツールアクセス・実行範囲を最小化（最小権限原則）し、AI活用レベルを実質的に下げる |
| タスク分割 | AI任せにする処理単位を細かく区切り、一度に自律実行させる範囲を狭めることでAI活用レベルを下げる |
| 説明責任設計 | 「なぜその判断か」を人が確認できる仕組みを作り、認知ギャップを縮小する |
| エスカレーション設計 | AIが判断に迷う・信頼度が低いケースを自動検知して人間に委ねる仕組みを作り、人の関与を増やす |
まとめ
生成AIの活用は、自律性とリスクのトレードオフを常に意識することが出発点となる。
- レベルが上がるほど価値は大きくなるが、認知ギャップも拡大する
- リスクの高いシステムでは、認知ギャップを意図的に抑制する設計が必要
- 「確認しているつもり」の状態がもっとも危険—可視化と人の関与点を設計で担保する
- AIを使う側のリテラシーとガバナンスが、技術的な実装と同等に重要
生成AIは「使いこなす」ものではなく、「正しく制御する」ものである。
2023年ふりかえり
１年に１回だけの記事ですが今年もふりかえりをします。
Keep
・自転車と水泳はずっと続いている。今年は念願の北海道に輪行ツーリングしてきた。留萌から羽幌・稚内、利尻島、旭川、富良野と周ってきた。楽しかった。来年も北海道には行きたい。
・週休3.5。仕事量を減らしてもらった。1,2週間程度の休みも何度か取れらしてもらっていい感じで働くことができた。来年も続けることができるかはわからないが、可能であればこのペースは気に入ってるので続けたい
・ChatGPTの利用。去年のふりかえりにGPT-3をあげているけどLLMの進化の早さに驚いている。プログラミングやデータ分析などで使っているけど素晴らしい。AGIを予感させるというか個人的には今のレベルで汎用性が高くAGIと言ってもいいように感じる
Less of
・FX。去年と逆でサヤ取りが封鎖されたので。ただ新しい方法を現在探索しているので復活はあるかも
・スピード。色々な意味でゆっくりと。急がない。焦らない。頑張らない。
Stop
・食べ過ぎ。常時食事を減らすというよりは、もったいないから食べるとかで不必要に食べてしまう行為をやめる。もったいない貧乏性？
・サウナ直後の水風呂。高血圧もちで血管イベントを避けるため。サウナはやめれないけどね。
More of
・ポタリングで今までに行ったことがないところ。東北とか。
・債券。債券利回りが高くなったのと保守的なアロケーションに変えていくため。
Start
・去年に引き続きスキー。冬の楽しみを増やしたい。あと冬キャンプも興味ある
・ITはやはりAGI系の新しい技術が出てきたらそれは追いかけていく
2022年ふりかえり
１年に１回だけの記事ですが今年のふりかえりをします。毎年KPTですが今年は Starfishでします。
Keep
・自転車と水泳はずっと続いていてこれは今後も続けたい
・今年はPower Platform（dataverse）での案件をやった。Power Platform自体はノンコード開発だけどその設定をするためのプログラムを作成した。ExcelからDB定義、画面生成、ページ、セキュリティなど90%以上は自動生成している。これってノンコード？。今後エンタプライズで成長がありそうな数少ないエリアなので最低限ですが気にしておく
Less of
・50代後半でFIREって言っていいかはあるけど、徐々に仕事量は減らしている。来年はさらに減らす予定
Stop
・個別株。別のうまくいく方法があるのでそちらにシフト。大型テックや優待銘柄の一部を残して年末売却した。
More of
・ポタリングは今年は念願の四国下半分に行けたのでよかった。来年は北海道か東北を回ってみたい。
・FX。現在の金利差でのさやとりのパフォーマスは満足いくもの。REIT・インフラファンドを売って全てFXで運用する。
Start
・スキー。学生の時にやっていて楽しかった思い出と、冬自転車にあまり乗れないのでその代替に
・ITで面白そうな技術としてはGPT-3かな。実際に応用できるレベルの知識はインプットしていこうと思っている
2021年
今年はいろいろなことがあって第３の人生について考えることが多かった年かな。
技術的には興味を持って取り組んだものはなくエンジニアとしての学びは少なかったのは残念。生活面のお金・健康・生きがいは安定していたと思うのでこれをキープ・発展させたい。
KEEP
PROBLEM
- プログラミングが面倒になった
以前はコードを書くのが楽しくてしょうがなかったが少し面倒になった。作るものの問題があるがもっと楽しくコードを書きたい。infoqとかの記事も読まなくなったので５年先の技術について語れなくなった - 高血圧
以前からで薬でコントロールしてたのですが最近血圧が高
くなってきた。 塩分コントロールは以前やっても効果がなかったけど今年はもう一度やってみることになった
TRY
- ノーコード/ローコード
仕事についてはpower platformでのビジネスが出てきてるのでもう少し深く考えてみる ノーコード／ローコードは昔からあるけれど出来る事が限られていて正直使い物 にならいと思っている。でも継続的にニーズが有るってことは、 良いソリューションが出来れば面白い領域で有ることは間違いなくいろいろ見て触って今後も考えてみたい。 - ファイナンス
50半ばなのでFIREについても選択肢になってきた今年前半はREITのスイングで調子良かったのですが後半は債券の代わりと思っていたインフラファンドでやられてしまった。 結局米国大型ハイテクのリターンが一番良かった 来年の戦略はお正月に考える - ラン
テレビの旅ランを見てやってみたくなった
2020年 ふりかえり
今年はコロナで在宅ワークが中心でした。
来年も在宅ワークは続きそうですが、コロナ後はどのような世界になるんでしょうかね。今年はStarfish(Stop, Less, Keep, More, Start)で振り返り。
Stop
Less
Keep
- Pythonにだいぶ慣れたNumPyとかPandasとかやっぱり便利。あとseleniumと組み合わせてweb スクレイピングは安定して使える
- KHSの走れる折り畳み自転車を新たに買って、コロナが下火になった合間にいろんなところに行った。これは継続。
More
- Rustは文法レベルはやった。色々面白い概念があって興味を持ったが、今のところ何か具体的な物は作っていない。WebAssemblyとかで何か作ってみたい。
- 個別のREITが平均回帰の特性や配当月前後の動きに傾向があるので、スイングトレードしている。年後半から初めていい感じなので来年も続けていく
Start
- Kaggle面白そう。これはこれから趣味でやってみたい。その中で見つけたGBDTを早速REIT個別銘柄の沸騰率予想に使っている。
