いろんな英語の用語
| 用語 | 意味 | 例 |
|---|---|---|
| homograph | 綴りが同じで意味が違う語（発音は同じでも違ってもよい） | lead（導く） / lead（鉛） |
| homophone | 発音が同じで意味・綴りが違う語 | write / right, sea / see |
| heteronym | 綴りが同じで発音と意味が違う語（homograph の一種） | content（中身） / content（満足した）, record（記録） / record（録音する） |
| homonym | 綴りも発音も同じで意味が違う語 | bank（銀行） / bank（土手）, bat（バット） / bat（コウモリ） |
| heterograph | 発音が同じで綴りが違う語（homophone と同義で使うことも） | there / their, piece / peace |
個人開発における成長を支える技術選定
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) のスタートアップ企業および公益法人である 。
間口が広い
