note-taking

ノート作成

このスキルを使うと、AI エージェントがノート作成のワークフロー全体を管理できます。構造化されたノートの作成、既存ノートへの追記、タグやカテゴリを使った整理、トピック別の検索と取得、ノートの要約などを行えます。ノートは設定可能なディレクトリに Markdown ファイルとして保存され、閲覧や取得が容易になる命名規則に従います。ミーティングノート、日次ログ、調査ノート、アイデアの記録、プロジェクトのドキュメントなど、さまざまな種類のノートに対応しています。

ワークフロー

1. ノートの種類と構成を決める： ユーザーの依頼に基づいて、ミーティングノート、アイデアの記録、調査ノート、日次ログ、プロジェクトノートなど、適切な種類を特定します。それぞれの種類には、関連するセクションを含む推奨テンプレートがあります（例：ミーティングノートには参加者、議題、議論、アクションアイテムを含め、調査ノートには情報源、主な調査結果、疑問点を含めます）。

2. ノートを作成または検索する： ノートディレクトリでファイル名と内容を検索し、関連するノートがすでに存在するか確認します。既存のトピックに追記する場合は、そのノートを開いて追記します。新しいトピックの場合は、内容がわかる日付付きのファイル名（例：2026-02-12-sprint-planning.md）で新しいファイルを作成します。

3. 構造化された内容を書く： セクションには見出し、リストには箇条書き、アクションアイテムにはチェックボックス、重要な用語には太字を使い、明確な Markdown 形式でノートの内容を記述します。後から取得しやすいように、先頭にメタデータ（日付、タグ、関連ノート）を含めます。

4. タグとリンクで整理する： トピック、プロジェクト、種類で絞り込めるように、ノートのメタデータにタグを追加します。必要に応じて関連ノートへのリンクを追加し、つながりのあるナレッジベースを構築します。

5. 取得して要約する： ユーザーが情報を求めたら、ファイル名、タグ、または内容でノートを検索します。「今月、認証について何を話しましたか？」のような幅広い質問には、ファイルの内容をそのまま返すのではなく、関連するノートをまとめて要約します。

使用方法

どのようなノートを作成するかをエージェントに伝え、内容を提供してください。エージェントが適切なファイルを作成または更新します。

Create meeting notes for today's sprint planning with the Backend Team.
Attendees: Alice, Bob, Carol. We discussed the v2.1 release timeline,
assigned the payment bug to Bob, and decided to defer dark mode to v2.2.

例

例 1：アクションアイテムを含むミーティングノート

ユーザーの依頼：

今日のデザインレビュー会議の議事録を作成してください。 参加者：Sarah（デザインリード）、Tom（フロントエンド）、Lisa（PM）。 新しいダッシュボードのモックアップを確認しました。Sarah が 3 つのレイアウト案を発表しました。 チームは案 B（サイドバーナビゲーション）を選びました。Tom は モバイル対応について懸念を示しました。タブレットでのテストが必要です。Lisa は 締め切りが 3 月 1 日であることを確認しました。アクションアイテム：Tom は 2 月 20 日までにレスポンシブなプロトタイプを 作成します。Sarah は新しいナビゲーションコンポーネントをデザインシステムに追加します。 Lisa は 2 月 25 日にフォローアップレビューを設定します。

エージェントが作成するファイル： notes/2026-02-12-design-review.md

ファイルの内容：

---
date: 2026-02-12
type: meeting
tags: [design, dashboard, ui]
attendees: [Sarah, Tom, Lisa]
related: []
---

# Design Review — Dashboard Redesign

**Date:** 2026-02-12
**Attendees:** Sarah (design lead), Tom (frontend), Lisa (PM)

## Discussion

- Sarah presented three layout options for the new dashboard.
- **Decision:** Team selected **Option B** — sidebar navigation layout.
- Tom raised a concern about mobile responsiveness, particularly on tablets.
- Lisa confirmed the ship deadline: **March 1, 2026**.

## Action Items

- [ ] **Tom** — Build a responsive prototype of Option B by Feb 20
- [ ] **Sarah** — Update the design system with the new sidebar nav component
- [ ] **Lisa** — Schedule follow-up design review for Feb 25

## Open Questions

- How does the sidebar behave on tablet screen sizes (768px-1024px)?
- Should we support a collapsed sidebar state for smaller viewports?

---

例 2：情報源を記録した調査ノート

ユーザーの依頼：

PostgreSQL のコネクションプーリング戦略について調査しています。これまでにわかったことをメモしてください。 PgBouncer は最も人気のある外部プーラーで、セッション、トランザクション、ステートメントの各プーリングモードに対応しています。ほとんどのウェブアプリではトランザクションモードが推奨されます。トランザクション間でコネクションを再利用し、通常はコネクション数を 10 分の 1 に減らせるためです。ただし、トランザクションモードではプリペアドステートメントに対応していないため、一部の ORM で問題が発生します。Pgpool-II は代替手段で、負荷分散とレプリケーションにも対応していますが、設定はより複雑です。Postgres の組み込みのコネクション上限は通常、デフォルトで 100 です。Supabase は、トランザクションモードの PgBouncer と Supavisor を使って 100 万以上のコネクションを処理していることを示すブログ記事を公開しました。

エージェントが作成するファイル： notes/2026-02-12-postgres-connection-pooling.md

ファイルの内容：

---
date: 2026-02-12
type: research
tags: [postgresql, connection-pooling, database, infrastructure]
related: []
---

# PostgreSQL Connection Pooling Strategies

## Key Findings

### PgBouncer
- **Most popular** external connection pooler for PostgreSQL.
- Three pooling modes: session, transaction, and statement.
- **Transaction mode** is recommended for web applications — reuses connections between transactions.
- Typically **reduces connection count by ~10x**.
- **Limitation:** Transaction mode does not support prepared statements, which can break some ORMs (notably older versions of ActiveRecord and SQLAlchemy).

### Pgpool-II
- Alternative to PgBouncer with additional features: load balancing, automatic failover, and replication.
- **More complex** to configure and operate than PgBouncer.
- Better suited for setups that need read replica routing in addition to pooling.

### Built-in PostgreSQL Limits
- Default `max_connections` is **100**.
- Increasing this significantly (e.g., to 1000+) causes memory and performance issues due to per-connection overhead.

### Production Scale Reference
- **Supabase** handles 1M+ connections using PgBouncer (transaction mode) with their custom Supavisor proxy.
- Source: Supabase engineering blog.

## Open Questions

- What is the performance overhead of PgBouncer itself at high connection counts?
- How do modern ORMs (Prisma, Drizzle) handle the prepared statement limitation in transaction mode?
- When does Pgpool-II's complexity become justified over PgBouncer?

## Sources

- Supabase Blog: "Scaling Postgres to 1M connections"
- PgBouncer documentation: https://www.pgbouncer.org/
- PostgreSQL documentation: Connection settings

ベストプラクティス

• 一貫した命名規則を使用します。 すべてのノートファイル名の先頭に ISO 日付（YYYY-MM-DD-topic.md）を付け、時系列で並べ替えられるようにし、ファイル名の重複を防ぎます。
• すべてのノートにメタデータを含めます。 YAML フロントマターにタグ、日付、種類、関連ノートへのリンクを記載すると、ノートを検索しやすく、相互につながりやすくなります。メタデータのないノートは、後から見つけるのが困難です。
• アクション項目はチェックボックスで記録します。 Markdown のチェックボックス（- [ ]）を使い、担当者名を太字にすると、アクション項目を見つけやすくなり、完了まで追跡できます。
• 自分の言葉ではなく、ユーザーの言葉でノートを書きます。 エージェントはユーザーの考えや決定を忠実に記録し、独自の意見を加えたり、意味が変わるような言い換えをしたりしないでください。
• 関連するノートにリンクします。 既存のノートと関連するトピックのノートを作成する場合は、related フィールドに相互参照を追加します。これにより、時間とともに自然なナレッジグラフが構築されます。
• 取得時には要約し、生のファイルをそのまま出力しないでください。 ユーザーが「ダッシュボードについて、どのような決定をしましたか？」と尋ねた場合は、該当するノートすべての全文を返すのではなく、関連する内容を簡潔にまとめて回答します。

エッジケース

• 内容が重複するノート： ユーザーが既存のノートと同じトピックのノートを作成した場合は、まず既存の内容を確認します。重複して作成する代わりに、既存のノートへの追記を提案します。ユーザーが両方を希望する場合は、ファイル名が異なることを確認します。
• 非常に長い会議ノート： 1 時間以上にわたる会議で議論が広範囲に及ぶ場合は、明確な見出しでノートを構成し、冒頭に要約セクションを設けることを検討します。200 行を超えるノートは、個別に読めるセクションに分割します。
• 機密情報を含むノート： ノートにパスワード、API キー、個人データが含まれている場合は、ユーザーに警告し、プレーンテキストの Markdown ファイルへの保存を避けるよう勧めます。認証情報にはシークレットマネージャーを使い、ノート内の機密情報はマスキングするよう提案します。
• 曖昧な検索依頼： ユーザーが広範なトピック（例：「データベース関連」）のノートを求めた場合は、タグと内容の両方で検索し、該当するノートを提示したうえで、どのノートを求めているのかを推測せず、対象を絞るよう尋ねます。
• ノートディレクトリが初期化されていない場合： 初回使用時にノートディレクトリが存在しない場合は、ディレクトリ構成と規則を説明するREADME.mdを作成し、ディレクトリも自動的に作成します。何も通知せずに失敗してはなりません。
• ノート間でアクション項目が矛盾している場合： 複数の会議ノートをまとめる際は、矛盾しているアクション項目や置き換えられたアクション項目（例：ある会議では「ダークモードを延期」、後の会議では「ダークモードに着手」）がないか確認します。最新の決定を提示し、変更点を説明します。