個人開発における成長を支える技術選定
3件売却
Webサービス構成辞典v3 （５年前） みんなバラバラ
ネイティブは
ReactNative
Reavt Native Webは癖が強い
UIは共通でいいが、Firebaseの接続周りは別
Firebaseの欠点 高度な検索
Turso supabaseも考えたが・・・DBと使うのはFAT
まず得意な技術でOK ー＞速さは正義
満たせない時は学ぶ 迷ったらサポート重視
新しい技術はAIは難しい Electron
Tauri 古いのと新しいのは混在
枯れた技術の方が無難
NextJS ー＞枯れた中ではいい ＋ Vercel ー＞２０ドルでいい感じに使える ＋ Supabase ー＞MCPもある
最も売りやすい技術構成 PHPで作られたサイト
プランニングと調査 ChatGPT or Gemini NitoAI 一度に２つ
全体の設計 Claude Oups
設計後のロジック実装 Curdor Composer
デザイン どのままだとAIパープル（AI臭い）になる？ Stitch→Gemini
金銭のやり取りとか 法律 外部つかう
自分のプロダクトを出したい がモチベーション
大きい会社でプロダクト作ってよに出ても 0.5%だなーみたいな感じ
自分が使いたいなーってので作った Webフォントの比較 利用規約 Notionをサイトにしたらいいじゃん
https://zenn.dev/nabettu/articles/013f114c7a1b44 https://nabettu.hatenablog.com/entry/single-develop
比較検討 タイパ
FigmaだったがAI
山下さんご講演 『つくりながら学ぶドメイン駆動設計実践入門』 —— 技術パターンの先にある「ビジネス価値」へのアプローチ
なぜドメイン駆動開発をするのか
↓正しいのか？ ロジックの整理 変更への耐性 パターンへの導入 ー>オニオン・クリーン〜アーキテクチャ など
間違いではないけど本質ではない 手段が目的になっているのでは？
あくまで副次的な効果
技術的な議論、ビジネスの議論が置き去り
中核を見極め競争優位性を最大化する
DDDをまず導入したいのは、その事業における最も重要な領域だ。 他のもので簡単に置き換えられるような領域には、投資しなくてもいい。投資すべきは、一筋縄ではいかない、もっと複雑なところだ。価値があって重要で、見返りが一番大きなところに投資する。 DDD本 ヴォーン・ヴァーノン
業務領域を分類する ↓ 中核を特定する ↓ 中核にドメイン駆動設計を導入する
イベントストーミング
戦略的設計 統合他者との差別化、業務ロジックの複雑さ
中核 ー＞境界
目的に特化 ロジック重視の境界
データのつながりではなく最小限
システム歯放置すると劣化
データの不整合を防ぎ実現
まとめ。 パターンは手段 本質はビジネス理解 作りながら学ぶ
既存のコードをなんとかしないといけない
全部をリファクタリングはできない 同じコードになりそうだけど、今やるべきじゃない判断
２０年くらい 原初２００３年
変化 エヴァンスの考えは古い 状況は変わった ２０２０年代は離れるようになった Lerning DDD カルチャーショック（現代的） エヴァンスのとは違う 仮説検証の結果がこの本
Vaughn Vernon（ヴォーン・ヴァーノン） https://zenn.dev/yamachan0625/books/ddd-hands-on
違うんじゃない？みたいな方向にはいかないと思う
AIで済ませるのは中核ではないところ
中核はAIにやらせるより自分達で考えるスキルを高める方がいい AIにアイディア、整理や壁打ちを自然言語にする 最終解のためではない
AIの普及による金太郎飴化現象
AI使うことが目的ではない 費用対効果あがってるよね？の視点で
新しい知識のキャッチアップ 会社のHP 業界のレポート 手に入るのだったら新人教育 こういう経由で発展したか 目指す特徴をざっくり掴む 明確に言ってくれるのが少ない 整合性がとれてなくて後から言われた
新しい事業につかえる 共通点みつかる 違いもよくわかる
コード例 WHYが必ず入っている 言語化するにはWHY なぜこれやるのか？ HOWをWHYに 読む人の理解
【AIエンジニアリング】オライリー翻訳者が語る、ソフトウェアエンジニアのためのAIシステム構築論 AIエンジニアリングの定義
AIエンジニアリング ―基盤モデルを用いたAIアプリケーション開発の基礎と実践
Chip Huyen 著、加賀谷 諒、菅野 憲也 訳
モデルの学習をするかしないか
MLエンジニアリング
AIエンジニアリング
LAG,AGENT,ファインエンジニアリング ML プロンプトで
AIエンジニアリング
調整する作業
機械学習の知識いらないけど 最低限のMLの知識は？ 最低MLの知識はあった方がいい デバッグとか知識あったらいい
海外 英語圏はエンジニアリング知らなくてもすごいのができる 知った方が便利 確率論的な挙動でどう向き合うか？
ソフトウェアエンジニアリングに近い領域 App作るの人はかわらない MLより決定論
プロント改善で実用レベルは厳しいケースはある
一番ライトな適用手法 プロンプト
適用と評価
RAG 知識とか社内の〜足りない時
ファインチューニング 固定したいとか、コスト下げたい
エージェント/ワークフロー 複雑な処理など、API更新とかを一律にやりたいなど
プロンプトからの具体的な判断基準 ファインチューニング
プロンプトに収まる範囲でやりましょう テキストに入れられる量は年々大きくなる MAXだったらいいとは限らない コンテキスト汚染
先頭の情報をつかいがちとか 真ん中忘れがち バイアスとか
本は2年前の情報 基本的な基礎知識
AIに任せないものは？ 書籍関連ではない・・・ ブログとか 自分でやって楽しいところとか
ファンデーションモデル 従来の機械エンジニアとは異なる 数学の博士号はいらないとはいってない
レイヤー
アプリケーション開発 ↓ モデル開発 ↓ インフラストラクチャ
質問増えたらキャッシュ 安全性のためにガードレール
シンプルに始めましょう
コンテキストの強化 LLM RAG入れる
コンテキストエンジニアリング LLMに対する
プロンプトエンジェクションを防ぐ フォーマット、JSONなど正しいか、はるしネーションがないか 入力と出力
ルーティング ユーザーの意図（インテント）を分類し、難易度やコストに応じて 適切なモデルや処理フロー（RAGを使うか、FAQで返すか等）に振り分ける
モデルゲートウェイ OpenAIやGoogleなど異なるプロバイダーのAPIを統一的に扱うインターフェース。アクセス制御、コスト管理、フォールバック（障害時の切り替え）などを一元管理
キャッシュの導入（コスト・レイテンシー削減） 過去の応答や計算結果を再利用するキャッシュシステムを導入 完全一致キャッシュ
セマンティックキャッシュ
同じクエリが来たら保存済みの応答を返す 意味的に近いクエリであれば、過去の応答を再利用 （ベクトル検索を使用）
[Step.5] エージェントパターンの追加（自律的なアクション） モデルが外部環境に対して「書き込み」や「複雑なループ処理」を行えるように
書き込みアクション メールの送信、注文の確定、データベースの更新など、現実世界に影響を与えるアクションを実行
ループ（フィードバック） 生成された応答をシステムにフィードバックし、タスクが完了するまで思考と実行を繰り返す
ジェミニのディープリーサーチ LLMに
書籍から紐解く、AIシステムの「育て方」とアーキテクチャ設計 ロードマップ-全体を支える横断的機能-
モニタリングとオブザーバビリティ ・監視：エラー検知、回答品質、コスト、レイテンシー、ドリフト（精度劣化）を継続監視。 ・トレース：クエリがどのコンポーネントを通り、どこで遅延・エラーが起きたかを追跡可能にする。
オーケストレーション ・パイプライン定義：検索、プロンプト構築、モデル実行、評価の一連の流れを定義。 ・データフロー管理：各コンボーネント間のデータの受け渡しを統合管理。
どこでエラーが起きてるかを検知できるか
運用するサイクル
データフライフホイール
Model、Data、Product
まずプロダクト作って、サイクルを回す
Product First まずプロダクト（デモ）を出し、ユーザーに使ってもらうところからスタート フィードバック収集 ユーザーの利用データこそが、他社と差別化する競争力の源泉となる 改善への還流 収集したデータを「評価用データ」や「ファインチューニング」に使い、システムを買くする
リジェクトなどのユーザの行動から推測
AIエンジニアのプロセス ある種特有な
モデルアップデート 新しいのがいいが プロンプトが変わってしまうので、アップデートしににくい 進化が激しい 癖がある
RAG掲載されているか？ こういう懸念点とかがある RAGの細かいこととか
アカデミックなつよみすみわけ AIエンジニアの捉え方AI開発
Anthropic Anthropic（アンスロピック、アンソロピック）とは、OpenAIの元メンバーによって設立されたアメリカの人工知能 (AI) のスタートアップ企業および公益法人である 。
間口が広い
アーキテクチャの沼へようこそー開発がもっと楽しくなる、不確実性を乗りこなす構造化思考
名前と型の違い 初速だけはやい
問題の顕在化が早くなった
AI化について AIに任せてもよしなにできるのは曖昧になりやすい AIを定めるのが設計 仕様工藤開発
アーキテクトの定義 ビジネス価値を最大化するために全体戦略を最適化する
機能性、セキュリティ性、再利用性~~
品質特性 品質要件の定義
要件を コード以外へのアプローチ 組織構造
チーム、ビジネス
ADL・・・アプリケーション決定記録 ADR(Architecture Decision Record) かな？
モブアーキテクティング
教育のためのAI
品質特性としてみてない？
品質特性は普段からやってるはず セキュリティ コード汚いー＞リファクタリング 可用性性を高める
機能性・・・顧客の満足を高めるもの
おかしいなと思うのがとっかかり
上の上の偉い人がやると思ったが自分がやる 小さいところだけやっても全体最適にかかるのでは？
ドメイン駆動設計
処理がバラバラに 停電対策用のモジュール 纏ってる方が保守性が高い
整理するフレームワーク 目的、手段の関係性
目的 目的は階層構造がある
仕様、どういう目的の達成のためなのか
目的、手段は一意となりやすいが 手段・・粒度による
コスパがいい
AIにはできない「人間ならではの判断」
目的を決めているのは人間 専門用語？ キミ？「〜は設置しない」？
コンテキストエンジニアリング AIがとりに行こう
所詮文字 言葉は劣化コピー
ドメイン駆動設計を始めよう
チームトポロジー
Team Topologie どんなチームではじめるか チームで意思決定していこう
アーキテクチャに労力を投じることに否定的・非協力的な人 仕事したくない？
ドキュメントを書く時、理由を書く 理由をふわっとしない なぜを ADRは書かせる
崇高なことがっていうより 大真面目にやれっていうのではなく大事な部分に対して投じる なにがなんでもこのアーキテクチャってわけではない 状況を見て解決 ってかいてる
JavaDocとかコードコメントを書かせる 自動化でルールを適用
コメントを入れて人間がビューしやすい形に
認知負荷を下げる→人間がレビューしやすい
小さくしたいか？ バートランド・メイヤー
３条件を満たしてモジュールをつくる メソッドの動作を保証するための3つの条件 事前条件（Precondition） 事後条件（Postcondition） 不変条件（Invariant）
３条件でテストが基本 小さく作っていく
顧客の目的を類推する 要件
品質要件 定義
パフォーマンス・・⭕️秒以内など
ドメイン駆動設計難しそう シンプル 正しく名前つけて定義しましょう
家電の話 電子レンジ、ドライヤー 合体したもの→誰が作った？ごちゃまぜになった →わける
目的設計
生成AIのコードのレビューどうするの？ 理解しているかどうかを確認 目的をするのを達成するコードか？ 説明できるか
Zenアーキテクト
アプレンティスシップ・パターン 学び方にフォーカスした本
AIモデル開発
目的・ 考え方の癖
・具体と抽象 ・認知特性・・・スキーマ理論
自分の知識や過去から
ジャングルの奥地の人を都会へ→電車を巨大な屁日
技術は手段
枠組みを外す
技術の言葉はお客さんの
エンジニア、抽象を具体にする仕事
抽象すること エンドユーザーに 思考のコントロール
ソフトウェア設計
全体設計、アーキテクト
アーキテクトは目の前にあるよ
