Rosarium

RETIRED · 13件

AI 6件

  • RETIRED 記事

    コード生成を使うべき場所

    AIにコードを書かせる前に、変更の影響を確認できるか、失敗時に戻せるかを考えます。必要なContext・テスト・人間レビューの費用を整理し、安全に採用できた変更で評価します。

    コード変更の委任・検証・反映権限を開発工程の設計として扱うため、独立した記事としての役割を終了しました。

    元の公開日：

    最終更新：

  • RETIRED 記事

    私が考えるAI駆動開発 ― AI・人間・成果物をどうつなぐか

    要件整理・既存仕様調査・設計・仕様化・実装・テストを一つのAI活用工程として考える。3つのAIを役割分担させた経験と、成果物を通じた受け渡しを紹介する。

    AI・人間・成果物をつなぐ考え方は、開発工程の委任・検証・反映権限の設計へ統合しました。3つのAIを使った保守の実務経験は、実践事例で読めます。

    元の公開日：

    最終更新：

  • RETIRED 記事

    「AIエージェントを0から作る時代」は本当に来るのか？

    自宅PCのストレージ整理を題材に、AIによる判断・ルール設計と既存ツールによる実行を分けて考える。MCPを試した経験から、エージェントの価値を接続先と責務の設計に見いだす。

    複数AIの役割分担と工程設計で扱うため、独立したページとしての役割を終了しました。

    元の公開日：

    最終更新：

  • RETIRED 記事

    設計支援AIは消えない。コード生成の次に残る領域

    コード生成と設計判断の性質の違いから、設計支援AIの役割を考察する。実装時間の短縮に加え、選択肢や責務を整理して人間の意思決定を支援する価値を論じる。

    この内容は現在の推奨ではありません。設計から実装・検証までの委任については「AIを開発工程に組み込む」で、検証・反映権限・復旧の観点から確認できます。

    元の公開日：

    最終更新：

  • RETIRED 記事

    AI時代において「レビューできる人」が価値を持つ理由

    AIの出力に対して、根拠を確認し、採否を判断し、責任を持てる人の役割を論じる。単にAIを操作することと、組織で安全に使える状態を作ることを区別する。

    この内容は現在の推奨ではありません。人によるレビューについては「AI出力の責任境界とHITL」で、採用・承認・実行の責任を確認できます。

    元の公開日：

    最終更新：

  • RETIRED 記事

    LLMを確率モデルとして設計するという立場

    LLMを次トークンの確率モデルとして捉え、出力の揺らぎと制約を整理する。プロンプトやRAGを小技ではなく、不確実性を前提とした出力分布の設計として考える。

    LLMを数学的・確率的な対象として扱う過去の考察です。現在の生成の仕組みと設計上の注意点は、AI理論の各テーマで確認できます。

    元の公開日：

    最終更新：

DX 4件

  • RETIRED 記事

    全員の業務が違うのに、AI活用事例をそのまま横展開できるのか

    成功事例のコピーではなく、目的・情報・品質条件を分解して自分の業務へ適用する横展開を考える。社内共有の経験から、AI活用を組み立てる前提知識と判断構造の重要性を述べる。

    AI活用を別の業務へ横展開するで扱うため、独立したページとしての役割を終了しました。

    元の公開日：

    最終更新：

  • RETIRED 記事

    生成AI教育はなぜ難しいのか ― 変わらない原則と変わり続ける実践を分けて設計する

    AIの操作を覚えるだけでなく、答えを確認し、使うか止めるか判断する力を育てます。責任境界・HITLの原則とツール別の実践を分け、業務の品質と工数から教育を見直します。

    AI教育を原則と実践に分けるで扱うため、独立したページとしての役割を終了しました。

    元の公開日：

    最終更新：

  • RETIRED 記事

    AIは自動化できる。しかし、その出力を確定値として扱ってはいけない

    AIが質問表へ自動入力した値が、確認済みの値と同じように扱われた事例を考える。候補・根拠・人間の確認・明示的な確定を分離し、判断を追跡できる入力工程を提案する。

    AI出力の責任境界とHITLで扱うため、独立したページとしての役割を終了しました。

    元の公開日：

    最終更新：

  • RETIRED 記事

    コード生成AIはなぜ業務を変えないのか — 設計支援として使うべき理由

    コード生成の高速化だけでは残る、業務の設計・責務分割・運用上の判断を考察する。AIを設計の理解・維持・改善に使い、意思決定の負担を減らす視点を示す。

    コード生成と設計支援を対立させる説明の役割を終了し、AIへのコード変更の委任と開発工程全体の評価へ統合しました。

    元の公開日：

    最終更新：

考察 3件

  • RETIRED 記事

    AIで作れる時代に、何を作らないか

    AIによって作る費用が下がるほど、作る前の選択と、残す・変える・統合する・終える判断が重要になる。生成量ではなく、価値とライフサイクルから作らないものを決める。

    IT戦略では「何を作らないか」も設計するで扱うため、独立したページとしての役割を終了しました。

    元の公開日：

    最終更新：

  • RETIRED 記事

    理解できないシステムは、コストである

    問い合わせのたびに再調査していた既存システムを、仕様・UI・処理関係から理解可能な状態へ整えた経験を紹介する。刷新の前に、調査結果を再利用できる知識へ変える意義を考える。

    理解しにくいレガシーシステムを、変更判断できる状態へ変えるで扱うため、独立したページとしての役割を終了しました。

    元の公開日：

    最終更新：

  • RETIRED 記事

    AIはどこへ進化しているのか — モデル競争の裏にある「構造」と「エコシステム」

    AIの競争を、文脈を蓄積する仕組みと構造を生成する能力という二つの観点から考察する。企業の固定分類ではなく、利用権限・評価・運用を含め、情報を価値へつなぐ条件を問う。

    AI企業をエコシステムと生成能力で二分する当時の説明です。現在の使い分けを判断する際には、モデル性能に加えてContextや利用条件を確認してください。

    元の公開日：

    最終更新：