2026-02-07

■

drawioのスキルよさそう

あとはスラッシュコマンドで下記を指定しておきたい・アイコンはAWS2026 ・あらかじめ用意したテンプレートベースで作成する・出力拡張子は .drawio.svg にしたい・コネクタのルールとかを明文化しておく

2026-01-04

Difyアップデート日誌 (docker, rancher desktop, macOS)

久々にアップデート地獄

DifyであたらしいLLM設定(Azure OpenAI)をしようとしたら、対象のLLM(gpt-5.2)が選択肢になくて、Difyの最新版をpullした。

docker composeするとエラー。どうもdocker cliのバージョンがふるくて、対応していないプロパティ(required)が使われている模様。 rancher desktopつかっていたので、rancher desktop最新版をインストール。起動後エラーが出て、dockerデーモンが起動しなくなる。

どうやらmacOSがふるくて、互換性がない処理がある模様。

macOSアップデート ( Monterey 12.0.1 -> Tahoe 26 ) 4年分の更新...放置しすぎた...

追記

Difyデフォルトからの変更点 macOS + rancher desktop環境でpermission関連のエラー対策で、 docker-compose.yml 内の各コンテナのuser指定でroot化

    user: "0:0"

docker/ssrf_proxy/squid.conf.template でproxy指定追加

dns_nameservers <DNSサーバのIPアドレス>
cache_peer <プロキシのIPアドレス> parent <プロキシのポート番号> 0 no-query no-digest no-netdb-exchange default login=<ユーザ名>:<パスワード>
never_direct allow all
prefer_direct off

ホスト側からのdocker全体の設定として~/.docker/config.json に下記を指定してみたが、difyの場合、squid経由なのであまり意味ないかも

  "proxies": {
    "default": {
      "httpProxy": "http://<ユーザ名>:<パスワード>@<プロキシのIPアドレス>:<プロキシのポート番号>/",
      "httpsProxy": "http://<ユーザ名>:<パスワード>@<プロキシのIPアドレス>:<プロキシのポート番号>/",
      "noProxy": "127.0.0.1,localhost,registry.example.com,dify.local,weaviate,qdrant,lindorm,unstructured,sandbox,ssrf_proxy,elasticsearch,kibana,plugin_daemon,172.18.0.0/16"
    }
  }

参考

ikubo.jp

2025-12-12

Teamsで使えそうなクエリ

検索条件の基本構文指定検索

from: ユーザ名 → 特定ユーザの投稿のみを検索

in: チャネル名 → 特定チャネル内の投稿を検索

sent: 日付 → 特定の日付に送信された投稿を検索例: sent: 2025-12-01

論理演算子

AND → 両方の条件を満たす投稿

OR → どちらかの条件を満たす投稿

NOT → 条件を除外

完全一致検索

"キーワード" → ダブルクォーテーションで囲むと完全一致

便利なコマンド

/オフライン → オフラインモードに切り替え

2025-11-25

SpecKitの成果物

geminiにまとめてもらった

この表は、SpecKitによる仕様駆動開発のプロセスを俯瞰的に理解するのに役立ちます。

👑 SpecKit 王道の実行フローと成果物一覧

順序	スラッシュコマンド	成果物（ファイル名）	成果物の詳細な内容
1	`/speckit.constitution`	`constitution.md`	プロジェクトの基本原則、ビジョン、制約条件。以降の全ての生成活動の根拠となる最上位の指針。
2	`/speckit.specify`	`spec/user_stories.md`, `data-model.md`	ベースラインの仕様書。システムが提供すべき主要な機能（ユーザーストーリー）とデータ構造の概要を確立。
3	`/speckit.plan`	`plan.md`, `spec/non_functional.md`, `research.md`	実装計画、アーキテクチャ設計、非機能要件。技術スタック、ロードマップ、性能やセキュリティなどの品質目標。
4	`/speckit.tasks`	`tasks.md` またはタスク管理システムへの連携	実行可能なタスクリスト。計画と仕様に基づき、開発者がすぐに作業に取り掛かれる粒度でタスクを分解し、優先順位付け。
5	`/speckit.implement`	`contracts/openapi.yaml`, `src/` ディレクトリ配下	実装コードと契約。確定した仕様に基づき、API仕様（OpenAPI）と、ビジネスロジックを組み込むためのコードの雛形を生成。

この王道フローは、設計の曖昧さをなくし、一貫性をもって実装へと進む、AI駆動型開発の理想的なサイクルを示しています。

👑 AIが導く開発の王道フロー：SpecKitによる完全自動化プロセス徹底解説

従来の開発は、仕様策定と実装の間に大きな断絶がありました。しかし、AI駆動型開発ツールSpecKitが提示する「王道フロー」は、この断絶を解消します。

SpecKitは、最上位の「憲法（Constitution）」からブレることなく、仕様策定、タスク分解、そして最終的な実装コードまでを一気通貫で自動生成します。

本記事では、この理想的かつ王道的な5ステップのプロセスと、各ステップで生成される具体的な成果物について解説します。

1. 🥇 憲法制定フェーズ：プロジェクトの原理原則を確立

開発の土台となる基本原則とビジョンを確立します。このステップがブレると、後のすべての工程に影響します。

コマンド: `/speckit.constitution`

成果物: `constitution.md`

成果物の役割	具体的な記述サンプル（日本語）
最上位の指針。すべての技術選定や機能決定の根拠となる。	ビジョン: 顧客の学習体験を劇的に向上させる、パーソナライズされた教育プラットフォームを提供する。制約: セキュリティリスクを回避するため、外部のサードパーティ認証サービスは最小限に留める。

2. 📝 仕様定義フェーズ：作るべき「機能」を明確化

憲法に基づき、「何を」作るかを定義します。ここでは、機能とデータの骨子が作られます。

コマンド: `/speckit.specify`

成果物: `spec/user_stories.md`, `data-model.md`

成果物の役割	具体的な記述サンプル（日本語）
機能要件。ユーザー視点で求められる具体的な機能の振る舞い。	ユーザーストーリー: AS ログイン済みのユーザー、I WANT パスワードを忘れた際にメールでリセットできる、SO THAT アカウントへ安全に再アクセスできる。
データ構造。後の実装に不可欠なエンティティとリレーションの定義。	データモデル: `Post` エンティティには `content` 属性（TEXT型）が必須。`User` (1) は `Post` (多) を持つ。

3. 🗺️ 計画策定フェーズ：どう実現するかの「戦略」を設計

定義された仕様を実現するための具体的な戦略（プラン）と、システムの品質基準を設計します。

コマンド: `/speckit.plan`

成果物: `plan.md`, `spec/non_functional.md`, `research.md` (調査結果も含む)

成果物の役割	具体的な記述サンプル（日本語）
実装戦略。アーキテクチャ、技術スタック、フェーズ分けを確定。	計画: フロントエンドとバックエンドは別々にデプロイする分離型アーキテクチャを採用。初期 MVP では、モノリスな構成から開始し、負荷増大に応じてマイクロサービス化を検討する。
非機能要件。システムに求められる品質目標。	非機能要件: サービス稼働率は 99.9% を目標とする。認証情報のハッシュ化には BCrypt を使用する。

4. ✅ タスク分解フェーズ：実行可能な作業単位へ分割

計画と仕様に基づき、開発者がすぐに着手できる最小単位のタスクへと落とし込みます。

コマンド: `/speckit.tasks`

成果物: `tasks.md` またはタスク管理システムへの連携

成果物の役割	具体的な記述サンプル（日本語）
作業指示書。個々の開発者に割り当て可能な、明確で具体的な作業項目。	タスク: `[DB] Post エンティティに対応する PostgreSQL テーブルの作成とマイグレーションスクリプトの作成。` 優先度: 高。見積: 4時間。
	タスク: `[FE] ユーザーダッシュボードの進捗表示コンポーネント実装。データ取得は /api/v1/progress に依存。` 優先度: 中。

5. 💻 実装フェーズ：契約とコードの自動生成

すべてのドキュメントと計画が確定した段階で、APIの契約を結び、コードの雛形を生成します。

コマンド: `/speckit.implement`

成果物: `contracts/openapi.yaml`, `src/` ディレクトリ配下のコード

成果物の役割	具体的な記述サンプル（日本語）
API契約書。フロントエンドとバックエンド間の通信規約をOpenAPI形式で確定。	OpenAPI: `/api/v1/posts/{post_id}` の GET メソッドのレスポンススキーマに `author_name` が必須で含まれることを定義。
実装コードの雛形。ロジックを肉付けするためのスケルトンコード。	コード雛形: FastAPI のルーティングと pydantic のスキーマ定義が完了した状態で、`# TODO: [ロジック実装]` のコメントだけが残されたハンドラー関数が生成される。

このSpecKitの王道フローに従うことで、あなたは仕様の曖昧さや手戻りを最小限に抑え、開発のスピードと品質を飛躍的に向上させることができます。ぜひ、あなたのプロジェクトでもこのAI駆動型開発の力を試してみてください。

2025-11-25

KIROのspec勉強(2025/11時点)

KIROが出力している情報を自作ソフトウェアで使った場合の体験にもとづき理解をしていく

requirements.md

構成は以下のとおり。機能名、ユーザーストーリー、受け入れ基準で構成された要件の羅列。

# 要件定義書

## 概要

## 用語集

## 要件

### 要件1：XXX機能

**ユーザーストーリー:** AAAAA

#### 受入基準

1. WHEN XXXする THEN システムはXXXすること

～要件の繰り返し

design.md

構成は以下。アーキテクチャ、コンポーネントとインターフェース、データモデル、正確性プロパティ、エラーハンドリング、テスト戦略など様々な内容で構成される。

# 設計書

## 概要

## アーキテクチャ

### システム構成図

### データフロー

## コンポーネントと インターフェース

### 1. AAAAA
**責任:** AAAAA

**主要API:**
- `POST /xxx` - xxxx

**WebSocket Events:**

### 2. AAA
**責任:** AAA

**主要機能:**
- AAAA

**インターフェース:**


### 3. AAA
**責任:** AAA

**サポートモデル:**
- AAA

**インターフェース:**

### 4. AAAAA
**責任:** AAAA

**サポートエンジン:**
- AAAA

**インターフェース:**

## データモデル

### AAAA構造

## 正確性プロパティ

*プロパティとは、システムのすべての有効な実行において真であるべき特性または動作です。本質的には、システムが何をすべきかについての形式的な記述です。プロパティは、人間が読める仕様と機械で検証可能な正確性保証との橋渡しとなります。*

### プロパティ1: AAAAA
*任意の*XXXXXに対して、AAAAAいること
**検証: 要件 1.1**

## エラーハンドリング

### XXXXエラー処理
- XXXX

### データ整合性

## テスト戦略

### プロパティベーステスト
プロパティベーステストライブラリとして**fast-check**を使用します。各プロパティベーステストは以下の要件を満たします：

- 各テストは最低100回の反復実行を行うこと
- 各テストには設計書の正確性プロパティを参照するコメントを含めること
- コメント形式: `// Feature: XXXX, Property {番号}: {プロパティ説明}`
- 各正確性プロパティは1つのプロパティベーステストで実装されること
- テストは実装に近い位置に配置し、早期にエラーを検出できるようにすること

**対象プロパティ:**
- プロパティ1-22: 上記の正確性プロパティセクションで定義された全プロパティ

### 単体テスト
単体テストは特定の例、エッジケース、エラー条件を検証します：

- 各サービスモジュールの主要機能テスト
- 空文字列、null、undefinedなどのエッジケース
- エラーハンドリングの動作確認
- モックを使用した外部依存の分離

単体テストとプロパティベーステストは補完的であり、両方を実装することで包括的なカバレッジを実現します。

### 統合テスト
- XXXX

### パフォーマンステスト
- XXXX

### 手動テスト
- XXXX

tasks.md

要件の実装、プロパティテストによる検証の実行計画

# 実装計画

- [x] 1. XXXX
  - XXX
  - _要件: 7.1, 7.2, 7.3, 7.4_

- [ ] 2. ZZZ
- [ ] 2.1 XXXX
  - XXXX
  - _要件: 7.1, 7.4_

- [ ]* 2.2 プロパティテスト: XXX
  - **Property 19: XXXX**
  - **検証: 要件 7.1**

tkhrsskの日記

技術ネタなど

■

Difyアップデート日誌 (docker, rancher desktop, macOS)

参考

Teamsで使えそうなクエリ

SpecKitの成果物

👑 SpecKit 王道の実行フローと成果物一覧

👑 AIが導く開発の王道フロー：SpecKitによる完全自動化プロセス徹底解説

1. 🥇 憲法制定フェーズ：プロジェクトの原理原則を確立

コマンド: `/speckit.constitution`

成果物: `constitution.md`

2. 📝 仕様定義フェーズ：作るべき「機能」を明確化

コマンド: `/speckit.specify`

成果物: `spec/user_stories.md`, `data-model.md`

3. 🗺️ 計画策定フェーズ：どう実現するかの「戦略」を設計

コマンド: `/speckit.plan`

成果物: `plan.md`, `spec/non_functional.md`, `research.md` (調査結果も含む)

4. ✅ タスク分解フェーズ：実行可能な作業単位へ分割

コマンド: `/speckit.tasks`

成果物: `tasks.md` またはタスク管理システムへの連携

5. 💻 実装フェーズ：契約とコードの自動生成

コマンド: `/speckit.implement`

成果物: `contracts/openapi.yaml`, `src/` ディレクトリ配下のコード

KIROのspec勉強(2025/11時点)

requirements.md

design.md

tasks.md

参考

👑 SpecKit 王道の実行フローと成果物一覧

👑 AIが導く開発の王道フロー：SpecKitによる完全自動化プロセス徹底解説

1. 🥇 憲法制定フェーズ：プロジェクトの原理原則を確立

コマンド: /speckit.constitution

成果物: constitution.md

2. 📝 仕様定義フェーズ：作るべき「機能」を明確化

コマンド: /speckit.specify

成果物: spec/user_stories.md, data-model.md

3. 🗺️ 計画策定フェーズ：どう実現するかの「戦略」を設計

コマンド: /speckit.plan

成果物: plan.md, spec/non_functional.md, research.md (調査結果も含む)

4. ✅ タスク分解フェーズ：実行可能な作業単位へ分割

コマンド: /speckit.tasks

成果物: tasks.md またはタスク管理システムへの連携

5. 💻 実装フェーズ：契約とコードの自動生成

コマンド: /speckit.implement

成果物: contracts/openapi.yaml, src/ ディレクトリ配下のコード

requirements.md

design.md

tasks.md

コマンド: `/speckit.constitution`

成果物: `constitution.md`

コマンド: `/speckit.specify`

成果物: `spec/user_stories.md`, `data-model.md`

コマンド: `/speckit.plan`

成果物: `plan.md`, `spec/non_functional.md`, `research.md` (調査結果も含む)

コマンド: `/speckit.tasks`

成果物: `tasks.md` またはタスク管理システムへの連携

コマンド: `/speckit.implement`

成果物: `contracts/openapi.yaml`, `src/` ディレクトリ配下のコード