メインコンテンツまでスキップ

Software Design 202511

AIツール​

観点は3つある。

  • 同期型 or 非同期型
    • 同期型は大きく難しいタスクに最適
    • 非同期型は小さく簡単なタスクに最適
  • GUI or CLI
  • 単一モデル or マルチモデル
ツール同期/非同期GUI/CLIモデル
Copilot同期型GUI単一
(VSCodeフォーク系)Cursor同期型GUIマルチ
(VSCodeフォーク系)Windsurf同期型GUIマルチ
(拡張機能系)Cline同期型GUIマルチ
(拡張機能系)Copilot Chat(Ask/Edit/Agent)同期型GUIマルチ
(拡張機能系)Amazon Q Developer同期型GUI単一
(拡張機能系)Gemini Code Assist同期型GUI単一
(CLI系)Claude Code同期型CLI単一
(CLI系)Codex同期型CLI単一
(CLI系)Gemini CLI同期型CLI単一
(CLI系)Amazon Q Developer CLI同期型CLI単一
(CLI系)Cursor CLI同期型CLIマルチ
(リモート環境動作系)Claude Code Web非同期型GUI単一
(リモート環境動作系)Devin非同期型GUI単一
(リモート環境動作系)Codex Cloud非同期型GUI単一
(リモート環境動作系)Google Jules非同期型GUI単一
(リモート環境動作系)Cursor Background Agents非同期型GUIマルチ

Copilot​

Issueに作業内容を書いてCopilotにアサインするとAgentモードでCopilotが実行され、PRが作成される。

Claude Code​

  • tabでthinkモード切り替え
  • .claudeフォルダ内のファイルはコンテキストとして自動で読み込まれので、知見はここに貯めると良いかも
  • .claude/commands/***.mdファイルを作ると、/***で呼び出せるカスタムコマンドになる

Amazon Q​

  • CUIでも、VSCodeの機能拡張としてGUIでも利用可能
  • AWSマネコンにも統合されており便利
  • モデルにはClaudeを採用

Gemini Code Assist​

  • いろいろできる子たちの総称？名前付けミスってる感じで全体像がちょっとよくわかんない
  • Gemini Code Assist
    • 機能拡張: VSCodeやJetBrainsの機能拡張として対話形式で利用可能
    • Gemini CLI: コード支援
    • Gemini for Google Cloud: Google Cloudのリソースを管理する
    • Gemini Code Assist for GitHub: IDEから外部サービス(Github,Jiraなど)と連携して色々やる

Devin​

  • クラウド型
  • 無限に並列化できる
  • チームの開発フローに溶け込む（PR作成, Slackでのやり取り、チケット更新、他）
  • 開発者が寝ている間ですら開発が可能
  • はじめからエンプラ向けに最適化されたアーキテクチャ

Cursor​

  • 深いAI統合がなされたコードエディタ
  • ローカル開発前提なので既存ワークフローと親和性が高い
  • 予測コンプリートが秀逸
  • インラインやチャットでの対話的編集が可能
  • エージェントモードを使うと実装完了まで走り切る
  • 全ファイルを探索してRAGによりコンテキストを取得するのが強力
  • 従量課金のため費用予測が困難
  • Rulesという仕組み（ファイル）で暗黙知をAIに伝える
  • Background agentを使うとリモート環境で独立してタスクを実行できる

オンコール​

障害が起きると、機会損失が発生し、信用も失墜する。 だから、数分から数十分の間に対応ができるオンコール体制が大事。

  • 広義の障害
    • システムが意図したとおりに動いていない状態
    • e.g. 処理時間が著しく遅い、ログにエラーが出ている、など
  • 狭義の障害
    • ユーザー体験に明確な支障が出ている状態
    • e.g. サイトが落ちている、エラー画面が出る、など

復旧とは、とりあえず応急的にもとに戻ったこと。 根本的な対策を恒久対応という。

障害対応の流れは、発生、初動、調査、復旧、報告、再発防止、である。

  • 発生
    • アラートにより検知する
      • ノイズとサイレンスを避けたアラート設計が大事
    • 初期報告をする
      • Slackのチャンネルで、発生日時、概要、影響、調査状況、仮の重要度(SEVレベル)、関係者、次回報告日時などを送る
      • スピードと不確実性の共有が大事
      • 分かっていないことをちゃんと明示する
      • その後も期限を決めて定期的に報告をする
    • インシデントコマンダーとDoerを置く
      • コマンダーは全体を俯瞰し、指揮、意思決定、情報発信、記録、対外連携に専念する
      • Doerは具体的な調査をする
  • 初動
    • 5分を上限にトリアージ（対応の要否や優先度ぎめ）を行うとよい
      • 影響が甚大なら、まず「止血」手段があるか評価し、必要に応じて実行する
      • その後、影響範囲の特定(レイヤー、時間軸、再現性など)
  • 調査
    • なぜそれが起きたかを明らかにする
    • ログやメトリクスを見ながら仮説と検証をチームで繰り返す
  • 復旧
    • 原因にあたりがついたら、ロールバックやスケールアウトなど、まずは復旧を行う
    • その後、恒久対応
  • 報告
    • 一次対応が収束したら、社内外への報告
    • 口頭だけでなく記録もする
    • 社外報告には、何が起きたか、いつ・どの範囲か、現在の状況、再発防止策、の4つを含める
  • 再発防止
    • なぜ発生したか、どうすれば検知可能か、どうすれば影響を抑えられたか
    • ポストモーテムは、障害を組織の知に昇格するプロセス
      • 時系列で客観的に事実整理しておく
      • 個人の責任追求はしない
      • 得られた知見は広く社内で共有する
      • 文化として根付かせるのが大事
      • トップダウンではなく現場主導で
    • 施策を考える（テスト自動化、設定ミス検知、Runbook整備、など）

障害対応で大事なこと

  • 冷静さを保つ
    • 一歩引いて俯瞰する
    • わかっていること、わかっていなことを整理する
    • 事実ベースで状況を捉える
  • 情報共有は大事
    • 全体の連携や判断を遅らせないため
  • 記録は大事
    • 行き違いを防ぐ
    • あとで役に立つ

アラート疲れを防ぐには:

  • 鳴らし過ぎない
  • 判断を減らす
    • Slack通知に、Runbookへのリンク、影響度、原因の候補などをあらかじめ書いておく
    • まず誰が対応すべきかが瞬時に分かるようにしておく
  • 対応者を労う文化を大事にする

ドメイン解体新書​

HTTPSレコードは、サーバ側が対応しているTLSのバージョンや、IPアドレスなどの情報を一度に取得できる。 2021年頃からモバイル端末で利用が始まっており、急速に普及している。 いまどきのデバイスは、サーバ負荷よりも効率性を重視し、最初にHTTPS/A/AAAAを同時に投げる。

DNS over HTTPS|TLS は、UDP/53を使わないので、通信が消えたように見える。 ただしDoHのサーバへの名前解決履歴だけは残る。

つまみぐい関数型プログラミング​

ElmはJSに変換される関数型言語である。

Elmでは、副作用を直接扱うのではなく、「副作用を起こすための命令」として、 Cmdという特殊な型で別に扱うことで、関数本体を純粋に保っている。

カリー化などで外から副作用をInjectするのではなく、 純粋関数の実行結果としてCmdを受け取り、それをElmランタイムが実行し、 得られた結果を別の純粋関数に渡していく、という点が面白い。 Result(Ok,Err)で成否を表現する。

ScalaはJVM上で動く関数型言語である。

関数型とオブジェクト指向を融合しているのが特徴。 enumで代数的データ型を定義する。enumはインスタンスメソッド的なものを持てる。 クラスメソッド的なものは「コンパニオンオブジェクト」で定義する。 Either(Left,Right)で成否を表現する。