Kiro IDEとAWSとNextDNSによるペアレンタルコントロール

こんにちは。
アプリケーションサービス本部、DevOps担当の兼安です。
今回は、業務ではなく個人で、Kiro IDEを使ってペアレンタルコントロールを作った話をします。
ちょっとしたアイデアを仕様駆動開発を使って形にした話だと思ってください。

はじめに
NextDNSによるペアレンタルコントロール
システム構成
Kiro IDEによる仕様駆動開発の流れ
PoCのSpec
実装のSpec
振り返りと課題
最後に

はじめに

今回ペアレンタルコントロールを作ったという話をしますが、これは私個人の家族における話です。
私も親が管理することが子育ての絶対正義とは思っていないことはご理解ください。

NextDNSによるペアレンタルコントロール

プライベートの話ですが、私には中学生の子供がいます。
スマホを持たせているのですが、どうしても深夜に漫画サイトを見てしまい夜更かし気味なので、家族で話し合った結果、自分で生活リズムをコントロールできるようになるまでは深夜帯にいくつかのサイトをブロックすることにしました。
これを実現するために、まずNextDNSというサービスを利用しました。

NextDNSはプライベートDNSを提供するサービスです。
スマホのプライベートDNSは、Androidであれば大体[ネットワークとインターネット] 次に [プライベート DNS] で設定できます。
（機種によって多少違うでしょう）
これを利用することで、スマホから特定のサイトへのアクセスを不可にできます。

NextDNS - The new firewall for the modern Internet

詳細な手順はNextDNSの公式を参照してください。
簡単に書くと以下の通りです。

NextDNSでプライベートDNSを構築
拒否リストに特定のサイトを追加
スマホのDNS設定でNextDNSによるプライベートDNSを使用するよう設定

flowchart TD
    A[スマホ] --> B[プライベートDNS<br>（NextDNS）]
    B -->|ブロック| C[特定のWebサイト]

こうすることで、そのスマホはプライベートDNS経由でネットに繋がるようになり、特定のサイトにアクセスできなくなります。
この方法の良いところは、プライベートDNSの存在と役割を知らないと解除するのが難しいところにあります。

さて、このNextDNSですが、デフォルトでペアレンタルコントロール機能が備わっており、いくつかのサイトが登録されています。
デフォルトで登録されているサイトは「娯楽時間」という機能で時間帯によるON/OFFが可能です。
デフォルトで登録されていないサイトは（私が知っている限りでは）「拒否リスト」でブロックできますが、こちらは時間帯によるON/OFFができません。

一方でAPIが公開されており、API経由で拒否リストのON/OFFが可能です。

NextDNS API Documentation | api

今回はNextDNSのAPIとAWSを組み合わせて、我が家の求めるペアレンタルコントロールをKiro IDEで実装しました。

システム構成

思い描いたシステム構成は以下の通りです。
Amazon EventBridge SchedulerでAWS Lambdaを深夜と朝にスケジュール実行し、NextDNSを操作します。
NextDNSの「拒否リスト」に私の子供がよく使うサイトを登録、LambdaからAPI経由で「拒否リスト」をON/OFFします。

Kiro IDEによる仕様駆動開発の流れ

上述のシステム構成を考えた上で、Kiroを用いて以下の2段階で開発しました。

PoC（＝技術的に実現可能か検証する）を行い、検証結果・プロダクト概要・技術スタックを書く
検証結果・プロダクト概要・技術スタックを元に実装する

正直なところ、技術的に問題はないことは見えていましたが、万が一できないことがあった場合にKiroのトークンと時間を無駄に消費するのは避けたいのと、細かく刻まないと適当な指示になって二度手間になった経験があるので二段階にしました。

blog.serverworks.co.jp

PoCのSpec

方針を決めたので、PoCのSpecを作って実行しました。
Spec作成を開始して、最初に入力したプロンプトはこれです。

NextDNSを用いて子供のスマホに対してペアレンタルコントロールがしたいです。  
深夜から早朝にかけては特定のサイトのアクセスを不可にしようと思います。  
NextDNSによるプライベートDNSをスマホにセットすることで、スマホの通信を制限できます。  
デフォルトのリストにあるドメインは「ペアレンタルコントロール」の「娯楽時間」によって時間帯によるON・OFFできます。  
一方、私がコントロールしたいのはデフォルトのリストにないドメインです。  
拒否リストというカスタムのドメインリストでコントロールできますが、これは時間によるON・OFFができないようです。  
NextDNSはAPIがあるので、APIを外部から叩き、それをスケジュール実行することでコントロールができないかと考えています。  
下記URLを参考に、実現可否を検証してください。  
https://nextdns.github.io/api/
アカウントは持っているのでAPIキーは取得できます。

このプロンプトでrequirements.mdができました。
この時点でPoCとして作るつもりだったことを思い出し、追加のプロンプトを入力しました。

一旦このSpecはPoCとしてください。  

簡単なテストコードなどを用いて検証し、docs配下にレポートとその後の本開発のためのプロダクト概要と技術スタックのドキュメント作成をゴールとしてください。

この後さらに、テストコードの実行は手動で行うという要件を追加して、requirements.mdを完成させました。
そして、design.mdとtasks.mdを作成しました。 tasks.mdの概要は以下の通りです。

プロジェクト初期セットアップ
NextDNS APIクライアントの実装
PoCスクリプトの実装
チェックポイント - 手動実行して検証
ドキュメント作成

4.はtasks.mdではこう書かれています。

- [ ] 4. チェックポイント - 手動実行して検証
  - `.env`ファイルを作成し実際のAPIキーを設定
  - `npm run poc`を実行して動作確認
  - Ensure all steps pass, ask the user if questions arise.

ここを手動実行としたのは、万が一変なスクリプトを書いてそれを一気に実行されると困るからです。
tasks.mdを確認後、実行して4.に差し掛かった時、以下のようなメッセージが出てちゃんと途中で止まってくれました。

手動実行した結果をプロンプトで追加入力してtasks.mdを続行し、検証結果とプロダクト概要と技術スタックが揃いました。

nextdns-parental-controls/
├── config/
│   └── schedule-config.json
├── docs/
│   ├── poc-report.md        # PoC検証レポート
│   ├── product-overview.md  # プロダクト概要
│   └── tech-stack.md        # 技術スタック
├── scripts/
│   └── poc.ts
├── src/
│   └── nextdns-client.ts
├── package.json
├── tsconfig.json
└── README.md

ここでできた技術スタックですが、後でいくつか課題があったことに気づきました。
それは後述するとして、実装に進みます。

実装のSpec

Specの作成画面で、PoCのSpecでできた検証結果とプロダクト概要と技術スタックを元に実装するように指示しました。
新たなrequirements.mdができたところで、要件の精度向上のためにAnalyze requirementsを実行しました。

Analyze Requirements - IDE - Docs - Kiro

Analyze requirementsすると、論理的な不一致、曖昧さ、ギャップがないか確認できます。

requirements.mdを開いてAnalyze requirementsを実行

このSpecでは、AWS Lambdaに与えるAWS Secrets Managerのパーミッションについて詳細な確認をしてくれました。

Analyze requirementsは、感覚的にaidlc-workflowsほど細かくはないですが適切な確認をしてくれる印象です。
requirements.mdをAnalyze requirementsで調整して完成したら、あとはdesign.md・tasks.mdと進めて実装するだけです。
実装は完了し、私の家族が望むペアレンタルコントロールは完成し、無事稼働させることができました。

振り返りと課題

実装はPoCなし一気にやっても完成していた可能性は高いですが、一旦実現可能なことを確認してから進める方が安心感がありました。
PoCのSpecは実装を後でやることを前提とし、レポートなどのドキュメントを作ることをゴールとしています。
実案件ではドキュメントを作ることがゴールのタスクは多いので、こういうSpecもアリと捉える方が私としては実案件に組み込みやすいと思います。

実装においては、Specで書いた技術スタックにいくつかの課題を感じました。

使用する言語（TypeScript、Node.js）のバージョンが微妙に古い
スケジュールの実装方法が微妙に古い（Amazon EventBridge SchedulerではなくてRuleを使用していた）
Lint・フォーマッター一式が揃っていない

今回の内容に限らず仕様駆動開発しているとこのあたりの不備は結構目にします。
主観ではKiro IDEに限らず他のツールでも発生するように見えます。
レビューする際はこういうことはよく起きるという前提のもと確認すると良さそうです。

実装が完了した後にIaCでデプロイしようとするとエラーになるのが見つかりました。
今回はIaCにAWS CDKを用いており、エラーの原因は単純なインポートエラーだったのですが、ユニットテストを実装させていたにもかかわらず抜けてしまいました。
これはtasks.mdのチェックポイントで、AWS CDKに対してユニットテストだけでなく、dry-runチェック（cdk synth）を入れておけば防げたでしょう。
早めに指示を入れておけば良かったと思います。
先回りして指示していた方が仕様駆動開発で消費するAIコストが下がりそうですし、この辺は気をつけたいところです。

完成までの所要時間はデプロイ後の手動テスト込みで4時間程度です。
実装完了までなら3時間弱です。
ただしこれは私が一定の経験があり、仕様駆動開発に抜けやすい箇所があることを既に知っているという前提知識があります。
この前提知識がない場合、所要時間は倍、または言語のバージョンが古いことに後になって気づくなんてことが起きると思われます。