タスクボード

2026-07-09 18:05 時点のスナップショット

閲覧専用です。承認・起票は次バージョンで対応予定 — 当面は秘書チャットで完結してください。
合計 10 OK 9 要確認 0 違反(非表示) 1
人間待ち 2ブロック 0進行中 3AI待ち 0未着手 4完了 0

人間待ち 2

背景・目的

PIIマスク/デマスクGUIアプリ(FKP本業向け)はP2 GUI完了・Windows開発環境確立済み。 次はP3本体=実データでのマスク精度調整(G3)。本番相当データを扱うため人間主導で進める。

2026-07-07更新: オーナーより「テキストなどの非構造化データも扱えるようにしてほしい」との追加要望があり、SDD STEP 2〜3を経て T-20260707-1 として実装着手を承認(未決-1=案S-A採用)。P3は表単体でなく、テキスト対応完了後に表+テキストを一括で実機評価する順序に変更。実機立会いコスト(宮﨑さん+Windows実機)を1回に集約するため。

要件・完了条件(受入基準)

  • T-20260707-1(テキスト対応実装)完了を前提条件とする
  • Windows実機で実データサンプル(表+テキスト)に対しマスク/デマスク精度を評価
  • 誤マスク・取りこぼし(zero_hit / unrestored シグナル)の調整
  • 精度が実運用水準に達したらP4(exe配布)へ

作業ログ / 引き継ぎ

  • 2026-07-01 (secretary): カンバン検証用に既存の進行中案件から起票。

実データ精度調整は作業Lv上「人間立会い必須」のため needs-human。 次アクション=宮﨑さんとWindows実機で立会いセッションを設定。

  • 2026-07-07 (secretary): オーナー承認の仕様書ドラフト(Dev/specs/fkp/fkp_llm_gateway_text_support_draft.md)を受け、P3の実施順序を「テキスト対応→表+テキスト一括評価」に変更。実装カード T-20260707-1 を新規起票しリンク。本カードのstatus/blocked_reasonは人間立会い必須のため据え置くが、前提条件に依存関係を追記。
停止理由 実データでのPIIマスク精度調整は宮﨑さんの立会いとWindows実機が必要(本番相当データのため人間主導)。加えて2026-07-07よりT-20260707-1(テキスト対応実装)完了が前提条件に追加。

背景・目的

FKP LLMゲートウェイ(PIIマスク/デマスクGUIアプリ)は現状「表(Excel/CSV)」専用。 オーナー要望「テキストなどの非構造化データも扱えるようにしてほしい」(2026-07-07)を受け、 SDD STEP 1〜2(Fable 5・engineering-devエージェントへ委託)で仕様書ドラフトを作成し、 2026-07-07にオーナー承認(STEP 3通過)。本カードはSTEP 4=実装を管理する。

仕様書(正本): Dev/specs/fkp/fkp_llm_gateway_text_support_draft.md(決定事項一覧=§14)

確定した設計方針: 共通コア(detect.py/vault.py/normalize.py=無変更流用)の上に、 表アダプタ(既存)とテキストアダプタ(新規 io_text.py 等)を並置する。

確定事項(§14):

  • 対応形式は .txt/.md のみ(案F-1・新規ライブラリなし)
  • 列ポリシーの代替は検知種別単位のオン/オフトグル(案P-2)
  • プレビューは件数+サンプル3件/種別
  • 出力ファイルの拡張子は入力を保持(.md_masked.md.txt_masked.txt。オーナー指定で推奨案から変更)
  • 出力エンコーディングは入力を保全
  • 文書サイズ上限は仮置き50万字(P3実測で調整)
  • engineering-redteam への委託は実施しない(Tier 2運用踏襲)
  • P3(実データ精度調整)との順序=案S-A:本カード完了後にP3で表+テキストを一括評価する(T-20260701-2 参照・実機立会いコストを1回に集約)

要件・完了条件(受入基準)

  • Step 1(コア): io_text.py 新規(読み書き・エンコーディング判定・バイナリ拒否・改行/拡張子保全)+単体テスト(2026-07-07完了・全190緑)
  • Step 1: mask.pyapply_mask_text/revert_text_report を公開(既存DataFrame関数のロジック不変・部品共有)
  • Step 1: チャンク分割+文書座標写像(文をまたぐPII・チャンク境界のテスト含む)
  • Step 2(パイプライン): pipeline.preview_text/mask_text/demask_text + CLIサブコマンド追加(2026-07-07完了・Fable・全203緑)
  • Step 2: obs.py にテキスト用イベントフィールド追加 — pipeline.py内のobs.log_event呼び出しで対応済み(chars/counts/replaced等・本文は記録しない)。obs.py本体のフィールド定義追加は不要と判明したため実質完了
  • Step 3(GUI): classify_paths 拡張・テキストモード状態遷移・種別トグル付きプレビュー(2026-07-08完了・Fable・全210緑)
  • Step 3: messages.py に新例外(TextDecodeError等)の平易日本語追加
  • Step 4(統合): E2Eテスト(マスク→AI改変想定→デマスク往復・改変耐性・抜け検出)— engineering-testing(Fable)委託・11件追加・実装バグ疑いなし
  • Step 4: 既存テスト全緑の維持(表経路の回帰ゼロ)— 最終221件全緑を自ら再実行し検証済み
  • Step 4: USER_MANUAL / OPERATIONS / ARCHITECTURE / TEST_PLAN 更新(engineering-dev(Fable)委託・git diffでdocsのみの変更と確認済み)
  • 実装完了後、engineering-testing へのテスト委託を検討 → 実施済み(上記)
  • 完了後 T-20260701-2(P3)を実装完了・実機立会い準備完了の状態に更新 — 次アクション

作業ログ / 引き継ぎ

  • 2026-07-07 (secretary): オーナー要望を受けFable 5(engineering-dev)へSTEP1-2を委託。

仕様書ドラフト作成→レビューHTML提示→オーナー承認(未決-5のみ推奨案から変更)。 仕様書に決定事項を反映済み。本カードを新規起票(実装未着手)。

  • 2026-07-07 (secretary): オーナーより実装着手の承認あり。「大規模一括実装」を避けるためStep単位で進行。

Step 1(コア: io_text.py・mask.py拡張・チャンク分割・TDD)をengineering-devへ委託し着手。 Step 2〜4は本Stepの完了・テスト全緑確認後に順次委託する。

  • 2026-07-07 (secretary): Step 1完了・全テスト190件緑を自ら再実行し検証済み(新規ファイル3件・テスト33件追加)。

オーナー指示によりStep 2以降はFableモデルで実装(Step 1は既に検証済みのため作り直さず活かす)。 Step 2(pipeline.preview_text/mask_text/demask_text・CLI・obs拡張)をFableへ委託し着手。

  • 2026-07-08 (secretary): Step 2完了・全テスト203件緑を自ら再実行し検証済み(pipeline.py拡張・テスト13件追加・CLI mask-text/demask-text動作確認)。

次アクション=Step 3(GUI)への着手可否をオーナーに確認。

  • 2026-07-08 (secretary): Step 3完了・全テスト210件緑を自ら再実行し検証済み(Fable)。

classify_paths4分類化・テキストモード分岐・種別単位トグル(案P-2)・messages.py例外追加。core/配下は無変更。 実機でのGUI動作確認(D&D→プレビュー→マスク→デマスク一気通貫)は自動テスト対象外のためStep4/P3実機検証へ引き継ぎ。 参考: 実装中にセキュリティレビュー(自動)がio_text.write_textのファイル権限(0o600等)を指摘したが、 既存io_table.write_table(Excel/CSV出力)も同様に権限制限なしで一貫しており、Tier2単一PC運用(鍵ファイルのみ0o600・ 出力ファイルは対象外という既存方針)と整合するため今回は見送り。将来的にoutput全般の権限強化をするなら io_table/io_text両方を横断で対応すべき論点として記録。 次アクション=Step 4(統合テスト・ドキュメント)着手可否をオーナーに確認。

  • 2026-07-08 (secretary): Step 4完了。テスト(engineering-testing・Fable)で仕様§7.2の統合テスト5項目のうち

自動化可能な1〜4を充足確認・11件追加(実装バグ疑いなし・チャンク境界の既知の限界は実運用リスク低と評価)。 ドキュメント(engineering-dev・Fable)でARCHITECTURE/OPERATIONS/TEST_PLAN/USER_MANUALの4ファイルに追記 (git diffで対象4ファイルのみの変更と確認済み)。最終テスト221件全緑を自ら再実行し検証済み。 §7.2項目5(GUI実描画のD&D→プレビュー→マスク→デマスク一気通貫)は既存方針により自動テスト対象外のため Windows実機での確認が必要=T-20260701-2(P3)に引き継ぐ。 status を needs-human に変更:オーナーレビュー待ち。承認後にP3側カードへ実機確認を反映する。

停止理由 実装・テスト(221件全緑)・ドキュメント更新は完了。オーナーレビューとGUI実機動作確認(P3のWindows実機セッションに合流)が残る。

進行中 3

背景・目的

営業課長昇任(2026-04)を機にFKPの正式DX推進体制を確立するプロジェクト。 5業務シート(提案・見積・受注・営業管理・経費精算)のAs-Is分析は完了。本業=本番運用のため人間主導。

要件・完了条件(受入基準)

  • 主要課題の順次解消:Salesforce設定過重/4重入力/週次レポート60分/帰社必須の経費精算
  • SFA=Salesforce継続(決定済2026-04-26)での運用設計
  • 弥生バージョン確認(未確認事項)

作業ログ / 引き継ぎ

  • 2026-07-01 (secretary): D区分バックフィルで起票。詳細状況の正本=memory project_fkp_dx_bprFKP/context/Challenges.md §5

本番運用中システムの変更はテスト確認→承認→反映(作業Lv.3人間必須)。

背景・目的

ottocraftのAI駆動型アプリ生成プラットフォーム(AppFactory)。Phase 1+2実装完了・動作確認中。 次はコミット&デプロイ。

要件・完了条件(受入基準)

  • Phase 1+2 の動作確認を完了
  • コミット(main直接)
  • デプロイ(テスト環境確認→承認→本番)

作業ログ / 引き継ぎ

  • 2026-07-01 (secretary): D区分バックフィルで起票。詳細状況の正本=memory project_appgen_platform

デプロイは作業Lv.3で承認必須。技術スタック=Next.js/Supabase/Cloudflare Pages/Gemini(承認済)。

背景・目的

Fable5の期間限定解禁を活用する作戦計画(承認済み)。頭脳強化ファースト (redteam→security→ottocraft→nippou)/実演→蒸留→型化で安いモデルを底上げ&トークン圧縮。実コードは優先低。

要件・完了条件(受入基準)

  • Fable解禁を確認したら着手
  • Phase 0=頭脳強化診断3本(redteam/security/攻撃シミュ)を実演
  • 型化(B)=Fable固有の鋭い視点を redteam/security 定義書へ蒸留・固定(commit ef38dd7=engineering-redteam.md/engineering-security.md にworked examples追記。攻撃系はFable安全ルーティングでOpusへ回るためredteam実演はOpus 4.8)
  • fkp-nippou で精度確認+スキル改善(whisper必須化/品質ゲート新設・commit ef38dd7・decisions.md記録)
  • 残りのFableタスク(ottocraft)で精度確認
  • アクションリストの軽量修正2件(④.claude/改ざん検知拡張・⑤Drive書込許可フェイルクローズ化)着手・完了
  • 蒸留した型を安いモデル運用に反映 → 残るアクションリスト項目(①鍵Drive同期外・②PII保護ツール鍵暗号化・⑥DMARC昇格・⑦都度承認)への着手

作業ログ / 引き継ぎ

  • 2026-07-01 (secretary): D区分バックフィルで起票。正本=.review/2026-07-01-fable5-limited-window-plan.html + memory project-fable5-limited-window

解禁タイミング待ちのため backlog。

  • 2026-07-02 (別セッション): Phase 0=診断3本 完了(読み取り専用・作業Lv.0・計約21.9万トークン)。統合レポート=.review/2026-07-02-fable-phase0-diagnostics.html

結論=「今すぐ危険な穴は無い。ただし自動化/公開を進めた瞬間に効く仕込みが複数」。3体が独立に同じ3つの根っこへ収束(①お願い≠柵②Driveミラーが見えない持ち出し口③入口封鎖は回り道で抜ける)。 優先アクション: (1)鍵/秘密をDrive同期外へ(=T-6と統合)(2)PII保護ツール配布前ゲート(=T-2関連)(3)AI組織にvalidate先行導入 (4).claude/を改ざん検知へ (5)Drive書込許可ID固定 (6)DMARC確認 (7)外部送信の都度承認…7/1摩擦低減方針と競合=オーナー判断。 次の一手=型化(B)(Opus)。診断で光った視点=「フェイルセーフの半身を疑う」「"外部に出さない"は保存先の同期先まで追え」を redteam/security 定義書へ焼き込む。

  • 2026-07-02 (別セッション→当セッションで発覚・commit ef38dd7): 型化(B) 着地済engineering-redteam.md(高次元の攻撃視点6+型・worked examples)/engineering-security.mdfkp-nippou/SKILL.md(whisper必須化・品質ゲート)へ蒸留反映。※これらはセッション跨ぎで未コミット滞留していたものを handover最終化コミットが同梱(メッセージ不一致・害なし・gitleaksクリーン)。残=ottocraftでの精度確認。以後は蒸留した型を安いモデルにチェックリストとして渡せる。
  • 2026-07-03 (secretary): 「診断結果を元に必要な修正を実施して」の指示を受け、優先度リスト7項目を実地検証してから着手。

既に別セッションで解消済みと判明=③validate導入(commit e171939)/「外部メモが信頼指示化」(commit 25df935 inboxディスパッチ+injection検知)/「掃除役AIの削除権限」(commit 1ab3503 退避のみ)。 今回実施(承認待ち60秒無応答→低リスクと判断し実行、事前に全項目を報告済み):

  • .githooks/health-check.shのCORE_RULES改ざん検知にAGENTS.md本体と.claude/settings.json.claude/hooks/*.sh3本を追加(旧版はsafety/ethics/web-service.mdの3ファイルのみでフック自体が改ざん検知対象外だった)。--update-hashesで基準再生成・--commitで全項目✓確認済み。commit前提でこのタスク保存と同時にcommitが必要。
  • ~/.config/gdrive-mcp/server.mjsisWithinWriteFolderをフェイルクローズ化(実地検証で実物のバグと確認:フォルダ名解決が0件の時に黙って全許可していた/corpora:"allDrives"のため個人共有等の同名フォルダも拾う設計だった)。正常系(現状の3設定=Workspace/FKP/GitHub)の挙動は不変、失敗時のみ拒否に変更。node --checkで構文確認済み。注意:このファイルはmachine-local(Drive同期外)のためMac限定。Windows機に別コピーがあれば同じ修正が必要(宿題)。

オーナー判断待ち(60秒無応答のため保留・次回確認): ⑥DMARC実測p=none確認済み→quarantine昇格の可否/⑦外部送信の都度承認復活は7/1摩擦低減方針と競合のため可否。 引き続き専用トラックで管理(今回は着手せず): ①鍵のDrive同期外移設=project-env-key-storage-reviewmemoryで別セッション提案予定のまま/②FKPゲートウェイの鍵暗号化(DPAPI)=P4配布ゲートとしてロードマップ済み・P3実データ調整(宮﨑さん立会い)が先。

未着手 4

背景・目的

ottocraft公式HPは2026-06-15に完全公開達成。運用フェーズの残タスクを消化する。 本番稼働中サイトのため変更はテスト環境(Cloudflare Pages preview)で確認してから反映(test-before-prod原則)。

要件・完了条件(受入基準)

  • DMARC ポリシーの昇格(none → quarantine/reject の段階昇格)
  • Services ページ新規作成
  • Content ページ新規作成
  • 旧名刺用 Google Sites からの橋渡し導線
  • Resend 使用量の月次目視(DoWバックストップ・別運用)

作業ログ / 引き継ぎ

  • 2026-07-01 (secretary): カンバン検証用に起票。優先度low。

ページ新規は要件確定後に web-design-proposerengineering-dev へ。公開=作業Lv.3で承認必須。

背景・目的

WorkspaceがGoogle Drive同期下にあるため、.env(APIキー等)がクラウドに露出しうる。 保管場所を見直す提案タスク(宿題)。鍵を扱うため risk Lv3。

要件・完了条件(受入基準)

  • 現状の鍵保管場所と露出範囲の把握
  • 安全な保管方式の提案(Drive外・環境変数・シークレットマネージャ等)メリデメ併記
  • オーナー承認 → 移行手順

作業ログ / 引き継ぎ

  • 2026-07-01 (secretary): D区分バックフィルで起票。詳細=memory project-env-key-storage-review

AIは .env を読み書きしない原則を維持したまま提案のみ行う。

背景・目的

Google Drive MCPが同期でnode_modules破損 → Mac側は修正済み。Windows側の修正が未了。

要件・完了条件(受入基準)

  • Windows機で ~/.config/gdrive-mcp の node_modules 再構築を確認
  • claude mcp list で google-drive 接続を確認

作業ログ / 引き継ぎ

  • 2026-07-01 (secretary): D区分バックフィルで起票。正本=memory project_mcp_gdrive_fix

再発時の解決策=cd ~/.config/gdrive-mcp && rm -rf node_modules && npm install(MEMORY.md 既知)。

背景・目的

自作スキル・テンプレ・保存プロンプトの棚卸し(.review/2026-07-03-スキル棚卸しレポート.html)で、 「まだ無いけど作るべきもの」として3提案が出た。オーナーから「AI組織用の新スキルは、AI組織プロジェクト 内で検討・実装したい。ここでは問題提起のみ」との指示を受け、実装はせずこのカードで起票のみ行う。

提案の中身(未実装・検討материал)

  1. /monthly-review — 月次点検(メモリ鮮度・gitleaksフルスキャン・ccusageコスト点検・allow棚卸し等)

の一括実行スキル。現状はMEMORY.md冒頭に散在する月次タスクを人間が思い出して指示する構造。

  1. カンバン自動実行(当初案/morningから方向転換) — オーナーの意図は「毎日自動でカンバンから

タスク確認して実行」というフル自律のデイリー実行。単なる手動トリガー型のスキルではなく、 スケジュール実行(cron/schedule)を伴う設計が要る。

  • ⚠️ 要検討事項: AGENTS.md §4 の作業Lv.3(git push・merge・deploy・本番反映・外部送信)は

「明示承認なしに不可」が原則。日次自動実行がLv.3操作を含むタスクに触れた場合、承認をどう挟むか (a. Lv.0〜2のみ自動実行してLv.3以上はneeds-humanのまま止める/b. 承認待ちキューを溜めて まとめて人間が朝に確認する、等)の設計判断が必要。Phase 3の「半自律・ドメイン別線引き」の 考え方(Dev/specs/ai-agent-org-system/phase3-crosscutting-infra-spec.md)と地続きの論点。

  • validate.sh・inboxディスパッチ・tpm-auditorなど既存のPhase 3インフラと統合する形が自然。
  1. /review-html.review/量産実績(30本超)はあるが手順がスキル化されておらず、メモリと

AGENTS.mdの記述頼み。人間向けレビュー成果物のみが対象(AI自身が参照する仕様書・スキル定義等は 従来どおり.mdが正・HTML化しない)。

完了条件(このカードの範囲)

  • AI組織プロジェクトの次フェーズ検討時にこの3提案を拾い上げる
  • 特に②はLv.3ゲートとの整合性を仕様として詰めてからSDD STEP1-3へ進める
  • 検討結果に応じてteam/assignee/statusを更新(実装フェーズに入ったらengineeringへ委託も検討)

作業ログ / 引き継ぎ

  • 2026-07-03 (secretary): 棚卸しレポートから起票。実装はせず問題提起のみでbacklogに置く。