目次

1. はじめに
2. Kiroについて
3. 実際に触ってみた
4. 感想
5. おまけ

1. はじめに

AIを使用してコーディングする場面を思い浮かべてください。
コード生成した結果、周辺とは違った書き方をされたり、余計な箇所を直されたり、意図しない修正をされて困った経験はありませんか？
他機能への影響が限定的な箇所や、とても簡単な機能の修正は、思い通りにいくことが多いですが、
他機能への影響が大きい改修など、機能の複雑度が高くなればなるほど上手くいかないことは顕著になりませんか？
本来はそんな(レバレッジの効きやすい)大規模な修正作業こそ、AIに任せたいものですよね。(しみじみ)

これらの問題の多くは、AIに「何を作りたいか」を正確に伝えられていないことが原因であることが多いと思います。
つまり、AIとの対話において、必要な情報を適切な形で提供できていないことが原因です。
プロンプトを調整したり、サービスとやり取りするチャットのセッションをリセットしたり、AIへの依頼方法を調整する行為をプロンプトエンジニアリングの上位概念として「コンテキストエンジニアリング」と言うらしいです。

調整したコンテキストをAIに依頼する。という熟練者達の暗黙知を
手段として提供しているAIコーディングエージェント「AWS Kiro」について、特徴や実際の操作についてまとめてみたので紹介します。

2. Kiroについて

AWS Kiroは、AIコーディングエージェントで、特にSpecモードが特徴的です。
公式ドキュメント

2.1. Spec駆動開発：AIとの対話を構造化する

従来のAIコーディングエージェントでは、「何を作りたいか」「どう作るか」はユーザの任意のタイミングで伝える必要がありました。
しかし、KiroのSpecモードは、開発プロセスを3つのフェーズに分けることで、AIとの対話を構造化してます。

• フェーズ1: 要件定義（Requirements）
  • 「何を作るか」を明確にする
  • ユーザーストーリーと受入基準を定義
  • この段階でレビュー・修正が可能
• フェーズ2: 設計（Design）
  • 「どう作るか」を設計する
  • アーキテクチャ、コンポーネント、テスト戦略を定義
  • 要件を基に自動生成され、レビュー・修正が可能
• フェーズ3: 実装計画（Tasks）
  • 「どの順番で作るか」を計画する
  • 具体的なタスクリストを生成
  • 設計を基に自動生成され、レビュー・修正が可能

この段階的なアプローチにより、各フェーズで必要な情報だけに集中することができ、AIに対して適切な情報を適切なタイミングで提供することができます。
結果として、AIが生成するコードの品質が安定し、意図しない実装を最小限にすることができます。

2.2. なぜSpec駆動開発が効果的なのか

Specモードの最大の特徴は、「AIに必要な情報を段階的に整理させる」という点です。

• 情報の整理
  • 各フェーズで必要な情報だけに焦点を当てられる
  • 前のフェーズの成果物が次のフェーズの入力になる
  • 情報の抜け漏れを防ぐ
• レビューポイントの明確化
  • 各フェーズで人間がレビュー・修正できる
  • 早い段階で方向性の誤りを修正できる
  • 実装前に要件と設計を確定できる
• 品質の安定化
  • 要件から実装までのトレーサビリティ
  • （ドキュメント次第ではありますが）プロパティベーステストを含む包括的なテスト戦略
  • 個々のエンジニアの経験に依存しにくい

つまり、Specモードは「AIとの対話の仕組み」そのものを改善することで、
（ある程度のレベルまでは）誰でも適切にAIに情報を伝えられるようになっています。

3.実際に触ってみた

今回はIDE版で進めていきます。
インストール・セットアップの手順については本記事では割愛します。
詳細は公式ドキュメントをご参照ください。

対象のプロジェクトに移動して「kiro .」でkiro.appが開きます
※kiro.appを開いて対象のプロジェクトを開くでも問題ないです。

「Spec」を選択して、早速以下のプロンプトを渡してみました

Kiroが requirements.md(要件ドキュメント) を作成してくれました
中身はこんな感じです

要件を確認して、修正したいところがあれば修正します。
今回はこのまま進めます。 Move to design phase を押下します。

要件に沿って Kiro が design.md(設計ドキュメント) を作成してくれました
アーキテクチャ、コンポーネント、データの永続化の方法論や、正常性プロパティ、テスト戦略まで、結構細かい粒度で設計をアウトプットしてくれました。

設計についてもこのまま進めます。 Move to implementation plan を押下します。

tasks.md(実装計画)が作成されました。
一部のタスクをオプション化してまずはコア機能のみの計画にするか or 最初から包括的に作成する計画にするか
聞かれたので、包括的に作ってもらいました。

Kiroにタスクの実行してもらいます。（チャットに「run all tasks」と入力） 実行中は以下のような感じで、進行状況がわかるようになってます。

最終的にできたアプリはこちらです。

• タスクの追加、削除、do/undoができる
• データの永続化ができてる（localstrageの範囲で）
• レスポンシブでシンプルなデザイン

4. 感想

「実際に触ってみた」のセクションで見てきたように、Specモードを使った開発では、
最初の簡単なプロンプトから

• 要件定義、設計、実装計画が段階的に生成
• 各フェーズで必要な情報が整理・確認することができ
• tasks.mdの実行中に何度かエラーが発生し（エラー解析＞修正を繰り返し）つつも、最終的に要件を満たすアプリを完成することができました

実際には、AIが提案する要件や、設計に対して、修正しながら進めていく事になると思います。
「要件定義、設計、実装計画」に時間をかける事で、品質や満足度の高いものを提供していければなと思いました。

AWS KiroのSpec駆動開発は、AIとの対話を構造化することで、品質を一定以上に得られる仕組みだと思います。
プロンプトの書き方ばかりに時間をかけるのではなく、最初から仕組み化されたツールを選ぶことも大切ですね。
ぜひ一度、試してみてはいかがでしょうか。

5. おまけ

AWS KiroにはCLI版の提供もあります。
以下の通り、インストール、pathの設定後に「kiro-cli」にて起動できます。 （メッセージは英語表示になってますが、日本語の質問すると日本語で返ってきました。）
エディターの縛りなく使用が可能です！！

最後に、「設計を明確にしてからAIに依頼することが大切」という観点でCursorのPlanモードについても記事を書いてます。
興味がありましたら、一緒に読んでいただけると嬉しいです。
CursorのPlanモードについての記事はこちら

最後の最後までお読みいただき、ありがとうございました。

目次

• 挨拶
• Amazon Connectとは？
• 目的と経緯
• 仕様
• 作業手順
• 作業内容
• 最後に

挨拶

こんにちは、システム部の長森です。
皆様は 自動音声応答システム（IVR） を利用したことはありますか？
IVRとは Interactive Voice Response の略で、架電時に音声が流れ、番号をプッシュすると適切なオペレーターまたは次の音声に繋がるシステムのことを指します。
企業への電話問い合わせ、商品の電話注文などによく使われているシステムなので、名前は初耳でもシステム自体は知っている！という方はきっと多いはず。
今回はこのIVRを体験できるサービスをAWSが提供するAmazon Connectを中心に用いて作ってみたので、その作成過程の全貌をご紹介したいと思います。

Amazon Connectとは？

アマゾンウェブサービス、通称AWSが提供するクラウド型コンタクトセンターサービスのことです。
クラウド上にコンタクトセンター機能が備わっているため、専用機器やコンタクトセンター運用のための場所を用意せずにコンタクトセンターを構築することができます。
またAmazon Connectは先に紹介したIVRや、電話をコンピュータと統合し、両者間でのやりとりと通信を可能にするCTI（Computer Telephony Integration）、顧客からの問い合わせに対し自動でオペレーターに振り分けるACD（Automatic Call Distributor）等のコンタクトセンターの運営に必要な機能に加えて、その他豊富な機能を標準搭載しています。
Amazon Connectに備わった各種機能は拡張性も高いため、満足度の高いコンタクトセンター運用が可能です。

目的と経緯

今回IVR体験サービスを作った目的は、ズバリ「お客様にAmazon Connectを体験してもらうこと」です。

「コンタクトセンターの業務がリモートワークに対応できておらず不便...」
「顧客との応対情報をデータ化できておらず顧客分析が不十分...」
「コンタクトセンターを立ち上げたいけど構築が大変...」

上記のようなお困りごとを抱えているお客様に、即座に問題解決可能！なAmazon Connectのサービスと便利さを知っていただくため、弊社HPのサービスページにてAmazon Connectの機能の1つであるIVRを体験していただこうと考えたのが今回の作成に至った経緯となります。

仕様

今回のIVR体験サービスでは、「本日のラッキー〇〇」を知ることができる、またはSMSにおみくじが送信される占い案内IVRを制作いたしました。
着電に対して実際に人が対応することはなく、自動音声案内のみで完結する仕組みになっています。
架電後、番号案内に従って1番を押すと「ラッキースポット」、2番を押すと「ラッキー方位」、そして3番を押すと「ラッキーフード」を知ることができ、4番を押した場合は「オリジナルおみくじ」が架電元の携帯電話にSMSメッセージとして送信されるようになっています。
また、冒頭に流れる挨拶と1~3番の音声については5時~17時の時間帯と、17時~29時の時間帯で音声内容が変化するお楽しみも加えてみました。


たとえば、ラッキースポットを知りたい場合は以下のような流れになります。


最後に、構成図は以下になります。とてもシンプル。

作業手順

今回のIVR体験サービスを作るにあたって、主に4つの作業をおこないました。

1. AWSアカウントと各インスタンスの作成
2. Amazon Connectの設定
3. Amazon SNSの設定
4. AWS Lambdaの設定

各作業の具体的内容について、以下で説明していきたいと思います。
具体的とは言いつつも、ところどころ情報を省略している部分があるため、実装の参考程度に見ていただければ幸いです。
それでは、さっそく見ていきましょう！

作業内容

AWSアカウントとインスタンスの作成
AWSのサービスの利用には言わずもがなAWSアカウントが必要です。
アカウントの作成が完了したら、必要となるAmazon Connect、Amazon SNS、そしてAWS Lambdaのインスタンスを作成します。

Amazon Connectの設定
作成したAmazon Connectのインスタンスの設定をおこないます。
設定として主にすべきことは、 ①電話番号の取得 と ②問い合わせフローの作成 の2つになります。

①電話番号の取得
AWSサポートを通じて番号取得申請をし、お客様が架電するための電話番号を取得できる状態にします。
申請する場合、選択肢の2つのうちどちらかではなく、右上の「サービスの制限の緩和をお求めですか？」からケースを作成して申請しないといけません。ミニトラップです。


ケース作成後、AWSサポートの担当者から以下4点の書類提出を求められます。

1. AWSから連携される申請書
2. 申請者の行政機関発行の有効な身分証明書 (運転免許証、パスポートなど)
3. 申請者と企業の関連性を示すドキュメント (社員証や、その他所属を確認できる書類）
4. 公共料金の請求書、法務省からの企業登録証明書 (登記事項証明書など)、行政機関からの領収書、国税または地方税に関する証明書 (納税証明書など)、社会保険料の領収書などの書類

場合によっては追加の書類提出を求められることがあります。
（私が申請した際は追加書類として企業登録証明書の提出を求められました。）
これらを提出して数日すると、担当者から電話番号の取得が可能になった旨の連絡がくるので、取得手順にしたがって番号を取得すればOKです。
今回の申請では追加書類の提出、また申請の間に大型連休を挟んだこともあり、申請から取得までに約3週間がかかりました。

②問い合わせフローの作成
Amazon Connectのフローで、「電話がかかってきてから電話が切れるまで」の音声案内のフローを作成します。
先述した仕様を実際の流れとして組み立てていくイメージです。


たとえば上記の問い合わせフローの一部では、「オペレーション時間の確認」で時間帯を判定し、判定された時間帯によって挨拶が変わるように「プロンプトの再生」を2種類に分岐させています。
その次段階である「顧客の入力を取得する」では番号案内のあとに押下される番号によって占い内容が変わるように分岐しています。
このように、機能ブロックから必要なものを選び、組み立てていくのが問い合わせフローでの作業となります。
フローが完成したら、フローを保存、公開します。
最後に電話番号の管理ページで取得した電話番号を作成した問い合わせフローに設定すれば、Amazon Connectにてやるべき作業は完了です。

Amazon SNSの設定
ここでやることも主に2つ、 ①サンドボックスの解除申請　と　②利用上限額の変更申請　が必要になります。

①サンドボックスの解除申請
Amazon SNSにはサンドボックスというものが存在し、通常の設定ではこのサンドボックスに事前登録された番号にしかメッセージの送信ができません。
今回のIVR体験サービスでは不特定多数の番号からの着電があることを想定しているので、このサンドボックスの制限解除を申請する必要があります。
Amazon Connectでの電話番号取得申請と同様に、サービスの制限の緩和としてケースを作成し、申請します。
申請の際に、「オプション」となっているまるで書かなくてもよいかのような項目を埋めずに申請すると、後日「情報不足で申請許可無理で〜す」と言われ追加情報を求められるため、最初の申請時に書けることは書いておくのがスムーズです。

②利用上限額の変更申請
Amazon SNSでは月額使用限度額というのも設定されています。
デフォルトでは限度額が$1/月になっているのですが、これでは月に約10件ほどのSMSしか送信できないため、限度額の変更を申請せねばなりません。
①のサンドボックスの申請解除と同じケース内にて申請可能なので、同時申請します。


AWSから以下のようなメッセージが届いたらサンドボックスの解除、使用限度額の変更は完了です。
（限度額を$4で申請したのですが、申請内容を見て気を遣ってくれたのか$100で適用してくれました。）


ただ、このままでは限度額の「最大値」はあがったものの、設定は$1のままになっているため、さらにAmazon SNSから自分で設定する必要があります。
テキストメッセージングの優先設定から設定可能です。
今回のサンドボックス解除とSMS使用限度額変更には申請から5日ほど要しましたが、はじめからオプション事項を埋めて申請していたらきっと1日程度で完了していたと思います、トホホ...。

AWS Lambdaの設定
AWS Lambdaでは、着電した電話番号宛にSMSを送信できるコード（関数）を作成します。
（コードについては今回省略いたします...！）
コード作業を終えたら、AWS LambdaがAmazon SNSの機能にアクセスできるようにするための設定をします。
AWS Lambdaの設定にある実行ロールからAmazon SNSのポリシーをアタッチしてあげればOKです。


AWS Lambdaですべき作業は以上になります。
これだけを見ると「Lambdaでの作業はすぐ終わりそうだなぁ〜」と思われそうですが、発展途上エンジニアの私はAWS Lambdaでのコード作業に一番手間取ってしまいました。
（指導してくださったベテランの皆様方には頭が上がりません、本当にありがとうございます。）

すべての作業が終わったら、きちんとIVR体験ができるようになっているか確かめるため、実際に電話をかけてテストをします。
今回、自動音声再生、SMSメッセージ送信の両方の確認が無事とれたので、これにて作業完了です！

最後に

今回はAmazon Connectを使ってIVR体験サービスを制作しました。
制作を通して、Amazon Connectの各種構築の素早さ、設定変更の容易さ等を実感し、その利便性の高さを再認識しました。
今回は実装しませんでしたが、Amazon Connectでは着電に対してオペレーターをつなぐ機能や、顧客とオペレーターの通話分析・通話の文字起こし機能なども組み込むことができます。
さらに、Amazon Connectは従量課金制のため、上記を含めたさまざまな機能を活用しても従来のシステムに比べてコストを抑えられる、という魅力までも兼ね備えています。
読者の皆様には、Amazon Connectについて知る第1歩として今回制作した占い案内IVRを体験していただければ幸いです。
サービスページにてお客様からお電話いただけることを楽しみにしております。
Amazon Connectの導入をご検討いただいた際には、ぜひ弊社お問い合わせページからご相談ください。

はじめに

私文大学生でクラウドの実務経験は皆無です。普段は機械学習などをぽちぽちしています。緊急事態宣言も解除され、次の試験受験を考え始めたので、次に活かせるようにソリューションアーキテクト c02に至った動機や学習方法をまとめていきます。 資格名そのままだと長いので、以降ソリューションアーキテクトアソシエイトをSAA、クラウドプラクティショナーをCLFと略します。

タイトルでは30時間で〜と謳っていますがSAAをパスするCLFに合格していますので、その時間も含めると全部で倍程度の間はかかっています。

動機

AWSとはなんぞや、クラウドとはなんぞやといった説明はわかりやすくまとめてくださっている先駆者がたくさんいらっしゃるのでここでは省略します。 サーバーまわりの細かい用語は応用情報の勉強である程度は前提知識はあると考え、あとは実際にサービスについて知っていこうと思い、それの指針としてCLFをひとまず受けてみることにしました。 SAAは、CLFでは基礎的すぎてもう1つ上くらいならすぐ行けるだろうと甘い考えで受験を決意しました。

資格習得のメリット

知識を取得していくうえで足がかりになる
資格試験全般に言えることかもしれませんが、資格試験のための勉強はがむしゃらにその分野を勉強するよりも、ある程度その道筋が整備されていることが多いです。 そのため、時間効率も高い上により知識を深めたいときに手を伸ばしやすいです。

褒められる
合格すれば褒められます。そして客観的な知識の証明にもなります。 何ももたずに「できる！」というより簡単に最低限のベースラインにいることが他者にも伝わります。

デメリット

資格一辺倒の勉強になりやすい
未経験からのスタートだと、実務を置き去りにしてしまうケースがあります。 特にAWSでは機能のアップデートも早いので注意が必要です。 しかし、言い換えれば、前までは使わなかったけれども新機能追加で日の目をあびるような組み合わせができるかもしれません。 多くを知っている分には損はないとは思います。

学習方法

ここでは実際に使ったサービスを使用頻度順で紹介していきます。

WEB問題集
https://aws.koiwaclub.com/
20h/30h
私はほとんどの時間をこのWeb問題集に費やしました。 AWSでは過去問の流用を禁じていて、公式から問題集もだしていません。しかしこのサイトは転載の可能なホワイトペーパー（後述）の文章を組み合わせて問題が作られているので相当実践に近い形の問題を解けます。 問題の解説も充実していますが、問題文、解説などすべてのコピペができなくなっています。解説にでてきたここの単語なんだろうとぱっと調べることなどができません。 また、解いた問題の保存機能などがありません。この問題は要注意だからといったチェック機能がありません。 そして有料です。CLFの問題を解くためにはダイヤモンドプランが必要で、90日5,000円ほどします。 しかし、これらのデメリットすべてを鑑みてもこのサイトはやる価値があると思います。 ある程度の下地があればこのサイト＋わからないものを調べる、で合格が可能でしょう。 だいたい3週ほどしました。

Black Belt
https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/
5h/30h
3倍速くらいで流し見しました。 AWS公式の方がサービス別にまとめてくださったものです。 基本的なサービスについてはYoutubeでのプレゼンもあります。 はじめは難しく感じましたが、わかったあとに見直すとめちゃくちゃわかりやすくまとまっていました。知識が足りないと思った分野のYoutubeがあればそれを見ていました。プレゼンのPDFだけだと眠くなってしまうので。。。

ホワイトペーパー
https://aws.amazon.com/jp/whitepapers/
3h/30h
上述のWeb問題集の解説にあるリンクから飛んだのがほとんどです。 公式ドキュメントです。死ぬほど眠くなります。文もイミワカランカタカナばっかりです。英語のほうが読みやすいんじゃないかみたいなのが膨大な量溢れています。 これしか学習教材がないときに取った方々は尊敬します。。

公式模試
1.5h/30h
解答探しを含めての時間です。 1回2,000円で受けられます。20問しかありません。解答はありません。当然解説もありません。最後に得点率だけ教えてくれます。 問題の傾向をわかるためにと勧めている方が多かったですが、私にはまったく役に立ちませんでした。どの問題を間違えているのかを分野でしか教えてくれないため、正解を調べても一抹の不安が残ります。自分が弱いところがわかる、という使い方もできますが、結局20問しかないので見過ごしてしまう可能性もあります。1回何かしらの試験に受かるとタダ券がもらえるのでそれを使わないでの受験はおすすめしません。 私が受けた試験はC02という2020年の3月末からの試験で私が受けた4月1日の段階ではほとんど情報が出回っていなかったのですがる思いで受験をしましたが、それでもあまり意味はないと感じました。難易度は体感で本番試験と同程度でしたが、出題範囲は本番のときは結構違いました。

海外のpractice exam
0.5h/30h
試験前日に寝る前にさわりました。 別の問題も見てみたかったので海外版Googleでaws saa practice free examと検索して登録しなくてもできそうなのをいくつかやりました。 上のWeb問題と似たような問題が多く、ひとまず安心しました。 やはり英語の資料や問題集は量が豊富でかつ値段も安いのでお得感がありそうでしたがすでに購入したWeb問題集があるので有効期限が切れたら試してみるのもよいかなと思っています。

公式のトレーニングセッション
https://aws.training/LearningLibrary
CLFのときはここから入りました。SAAは受けていませんが、概要を知るには良いと思います。

勉強時のポイントなど（雑記）

教材は最低限からスタートする
性格の違いもあると思いますが、私は最低限の教材を買って足りないと思った分だけ少しずつ足すようにしています。あまりにやるべき量が多いとそれだけでノックダウンしてしまったり、やっぱりやめたとなってしまうからです。

とりあえず申し込む
テストセンターによると思いますが、会場は休日でもない限り前日でも予約でき、キャンセルは前日までできます。受験料も全額返ってきます。 人は締切が設定された瞬間に強くなります。 私もSAAを受けるときにもう少し伸ばそうと思っていたら緊急事態宣言が出そうだったので涙をのんで前日のキャンセルタイミングをスルーしました。 自分で設定した締切＋緊急事態宣言という締切によって逃げられなくなりがんばれました。 とりあえず申し込めば、キャンセルする手間が出来る分何もしないときよりも切迫感を味わえるのでとりあえず申し込んでみるのも手だと思います。

やっぱり実際に使ってみる
暗記の部分に関してはなんとも言えませんが、やはり覚えるときに理由付けがあると効率が全然ちがいます。私は実際に手を動かしたのは簡単なゲームサーバーを建てたくらいですべてのサービスに手を付けたわけではありませんが、そこでやったことは記憶に定着しやすかったです。私はこれが足りず、コスト最適化アーキテクチャが再学習の必要ありの評価でした。

本試験での文章のおかしさ
これも巷に言われていることですが、本試験の文章はおかしなところが多いです。C02の最新の試験のはずなのにいくつかおかしい場所がありました。root userとなるべきところがルートルートと訳されている場所もありました。英語版に慣れておくのもよいかもしれません。

SAA取得で感じたメリット

取ってすぐはそこそこできるようになったかな、という見えない自信くらいでした。まぁ資格を取ったので取っていないよりは見える化出来ていますが。。。 強く成長を感じられたのは新たにdvaの学習を始めたときでした。 上でホワイトペーパーをワケワカランと評していますが、スルスルと読めるようになっていました。
あんなにカタカナがソーマッチなのにWhy？
→SAAで基礎部分を学んだおかげで自然と適応していた。かなと思います。
ただまだまだ読めない部分もあるのでこの調子で学習を続けていきます。

おわりに

総勉強時間はCLFが20時間ほど（1週間）、SAAが30時間(1.5週間)の計50時間ほどでした。どうせ暇なんだからもう少しやれという感じですが。 クラウドは勉強して感動、使ってみて感動のすごいサービスだと思ったので。今後はより広く深いレベルの知識習得を目指します。また、同じクラウドサービスのGCPなども比較してみたいと思うのでこの知識を足がかりにそちらの勉強にも足がかりになればいいなと考えています。

Twitter・Facebookで定期的に情報発信しています！
Follow @acceluniverse

AUCのAWS環境構築はEBがメイン

　こんにちは。社員の大田です。この秋就任したCTOに、うちの会社の諸々のAWS環境について少しだけ話を聞く機会がありました。

　僕は若手なので日々勉強をしながら、プロジェクトの隅っこで小さな仕事をしています。AWSに関してはちょうどこの冬あたりからSAAの勉強を始めました。大体のサービスのかんたんなことは知っているつもりですが、何しろ、インフラ周りは全体に影響がでる大切なところなので、これまであまり実環境に触れることはありませんでした。

　CTO曰く、うちの開発はEB(ElasticBeanstalk)をよく使うということでした。GIthubでコミット＆マージしたものを、CircleCIを通して、EBで組んだ環境にデプロイするパターンが多いようです。

　EB(ElasticBeanstalk)とはAWS上のインフラ構築を自動化してくれるサービスです。

Elastic Beanstalk では、アプリケーションを実行しているインフラストラクチャについて学習することなく、AWS クラウドでアプリケーションをすばやくデプロイし、管理できます。Elastic Beanstalk は、選択肢を狭めたり制御を制限したりすることなく、管理の複雑さを軽減します。アプリケーションをアップロードするだけで、Elastic Beanstalk が自動的に容量のプロビジョニング、負荷分散、拡張、およびアプリケーションの状態のモニタリングといった詳細を処理します。

https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/Welcome.html

　たとえば僕のような初心者でも、EBを使えばかんたんにアプリケーションのインフラ構築ができます。ALBを立てて、TargetGroupを作って、AutoScalingの設定をして、、といったことにいちいち頭を悩ます手間を省くことができます。

　また、デプロイも容易に行えるため、コミットから反映までのリードタイムをできるかぎり小さくできるという利点もあります。これは、スピーディにプロジェクトを進めるためには、とても大事なことです。

　もちろん、相当大規模で複数なシステムの場合は、細かな部分に慎重に配慮する必要があります。けれども、一人ひとりが複数のプロジェクトに関わりながら、スピード感をもって仕事をしていかなければならない以上、EBを用いたインフラ構築＆管理がメインになるのは、当然のことなのだなと思いました。

　ただし、EBも万能なわけではありません。煩雑な作業を自動化してくれるとはいえ、一つ一つのリソースが裏で絡み合っている以上、何か問題があったときには、それらの細かなところに踏み入って対処しなければなりません。

　そんなときに無駄にハマってしまうことがないように、僕ももっと勉強をしなくちゃならないなと思います。年末年始はいつものように寝ていないで、ちょっとがんばりたいですね。

2018年4月から2年目を迎えた。森久です。

前々回はHerokuについて紹介致しました。
https://www.acceluniverse.com/blog/developers/2018/04/heroku-part1.html

前回はHerokuのアドオンついて紹介致しました。
https://www.acceluniverse.com/blog/developers/2018/06/heroku-part2.html

今回は題名にもある通りアドオンで詰まった備忘録を記載致します。
詰まったアドオンは「QuotaGuard Static」です。

結論から記載すると原因はHeroku Schedulerの一時的なDyno（one-off dynos）に関して設定がなされていなかったためです。

要件は下記になります。
1. アプリ自体をHerokuのPrivate Spaces（AWS VPCを用いた隔離環境）からCommon Runtime（Private Spacesとは逆にpublicに開かれた環境）に移行する。
2. DBはシステムの構成上、Private Spacesに残す。
3. DBにアクセスし更新するバッチはHeroku Schedulerにて設定している。(Common Runtime上)

※AWSとはクラウドサービスで、HerokuはAWS上で動いています。
AWS VPCについては以下を参照してください。（今後ブログで紹介するかもしれないです。）
https://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Introduction.html

QuotaGuard Staticの手順に則り下記のように設定を進めました。
少し詳細を説明させていただくと、まず接続するにあたって、HTTPプロキシを使用するかSOCKS5プロキシを使用するかを決めます。
今回はDBにアクセスするためSOCKS5プロキシを指定しました。（Herokuの公式によるとwebはHTTPプロキシ・それ以外はSOCKS5プロキシがオススメだったため）
参考：https://devcenter.heroku.com/articles/quotaguardstatic

SOCKS5プロキシを使用して「Common Runtimeのアプリ」から「Private SpacesのDB」にアクセスするにはproxyを通す必要があります。

Proxyの通す方法

1. 下記コマンドでpgtunnelをインストール

2. Procfileを編集（Dynoの設定を記述するファイル）
web: bin/bgtunnel アプリケーションサーバ名 ドキュメントルート
上記の「bin/bgtunnel」を先頭に付けることでDynoに対しproxyを通せます。

準備は整いました。新たにCommon Runtime上でproxyを通したアプリ(Private Spacesで展開していたアプリと同様のもの)を作成します。
ログイン画面に遷移し、ログイン情報を入力するとログインできました。（ログイン情報はDBに格納）
これでDBに接続できることは確認できました。

～～数日後～～

バッチが動いていません...
下記エラーが発生していました。

DBに接続できていない。先ほど記載した通りログインはできますし、アプリからDBの更新処理も行えます。
調査を行いましたが分からず、Herokuに問い合わせました。

迅速な対応をしていただき、共に調査を行なったことで原因が判明。
アプリのDynoにはproxyを通したためDBに接続できましたが、Heroku Schedulerはバッチ処理を行う際、一時的にアプリとは異なるDynoを立ち上げます。
そのDynoにはproxyが通っていないためDBに接続できなかったのでした。
一度気づけば、納得ですが気づかないと詰まると思いました。（他のアドオンとかでも場合によっては起きそう）

proxyを通し無事解決

まとめ

1. Heroku Schedulerで立ち上げるDynoはアプリのDynoとは別物（もはや関係すらない）
2. Herokuに問い合わせた際の対応が迅速でよかった。

以上3回に渡ってありがとうございました。

2018年4月から2年目を迎えた。森久です。

前回はHerokuについて紹介致しました。

https://www.acceluniverse.com/blog/developers/2018/04/heroku-part1.html

今回は題名にもある詰まったアドオン「QuotaGuard Static」も含め、弊社で使用しているものを4つほど紹介致します。

Herokuアドオンとは？
Herokuの拡張機能の事です。
アプリの運用をよりリッチにしてくれます。
管理画面から適用する事も可能ですし、コマンドで適用する事も可能です。

公式ホームページ
https://elements.heroku.com/addons

1. Librato
https://elements.heroku.com/addons/librato

アプリのメトリクスを監視するアドオンです。
負荷やHTTPステータス、リクエストタイムなどの情報を蓄積・確認できます。
また、他のサービスと連携し、データベースへの負荷を確認したり、閾値を指定すればアラートを飛ばしたりもできます。
無料枠もあるため、1アプリに1つあると非常に便利です。

2. Papertrail
https://elements.heroku.com/addons/papertrail

アプリのログを収集・確認できます。
流したSQLや、エラーなどがログに残るため、調査に非常に便利です。
また、検索機能を保存することによって確認したいログを即座に抽出できます。
ただ、独特な検索仕様ですのでリファレンスを確認し把握しておくと良いと思います。

https://help.papertrailapp.com/kb/how-it-works/search-syntax/#quick-reference

3. Heroku Scheduler
https://elements.heroku.com/addons/scheduler

今回詰まった要因の一つでもあるアドオンです。
指定した日時に処理を実行してます。
主にバッチ処理で使われますが、一時的なDyno（one-off dynos）を立ち上げて処理を行います。
時間はUTCで指定するので注意してください。

4. QuotaGuard Static
https://elements.heroku.com/addons/quotaguardstatic

Herokuでは最新のソースをDeployしたり、環境変数を変更する度、IPアドレスが変わります。
例えば、IP制限のかかったリソースにアクセスする際は、毎度IPアドレスが変わるため不都合が生じます。
そういった不都合を解決するため、静的IPアドレスを作成・アタッチしてくれるのがQuotaGuard Staticです。
静的IPアドレスが紐付けられれば、そのIPアドレスを指定するだけでアプリのリソースに接続できるという訳です。
他にも2つの静的IPアドレスによる自動フェールオーバーできたりと色々機能があります。

他にもDBやRedisといったリソースもアドオンとして提供されています。
アドオンはまだまだたくさんありますので、有効に活用できるよう勉強していきたいです。
では次回はいよいよ「QuotaGuard Static」で詰まったところを紹介致します。
ありがとうございました。

2018年4月から2年目を迎えた。森久です。

今回は案件で使用したHerokuのアドオン「QuotaGuard Static」に関して詰まったところを紹介致します。

ただその前にHerokuとは何か。私の勉強も踏まえて振り返っていきたいと思います。

Herokuとは？
Webサービスを開発から公開まで簡単に行なってくれるPaaS（Platform as Service）という形態のサービスです。

PaaS？プラットフォーム？よく分かりません。

PaaSとは？
ソフトウェアを構築および稼働させるための土台となるプラットフォームを、インターネット経由のサービスとして提供します。

難しく考えるとややこしくなりそうですが、プラットフォームは'アプリを動作させるための土台'ということは分かりました。
お家でいうところの柱や骨組みといったところです。他にも色々な意味を持つそうですが。

実際アプリを公開するにはサーバーを用意したり、インターネットに接続できるようにしたり、柱や骨組みを作るだけでとても大変です。

そんな骨組みをインターネット経由で提供してくれて「後は好きなように家を作ってください」と場を整えてくれるのがPaaSのサービスです。

また、生活していく中で荷物や人が多くなり家が狭くなると住みづらくなります。解消するにはリフォームしたり、もう一軒最初から建て直したりしなくてはいけません。
アプリも同じように、運用していく中で負荷が多くなり、処理が遅くなります。

そんな時、Herokuでは、サイト上で簡単にスケールアウト（サーバーを増やして処理能力を向上させる）すること、つまり、全く同じ家をもう一軒作れます。
そうすることで、処理を分散したり、片方が障害で動かなくなっても、もう一台で処理を担うことができます。

アプリの機能に合わせてスケールアウト・スケールイン（逆に減らすこと）できるので、最低限のコストで済みます。

上述の骨組み（プラットフォーム）はHerokuにて「Dyno」と呼ばれております。
そして料金は使用しているDynoの数と時間、種類で決まります。

下記参照
https://www.heroku.com/pricing#dyno-comparison

では次回は「アドオン」と呼ばれるHerokuの拡張機能についてまとめたいと思います。
ありがとうございました。

こんにちは。

弊社では、HPの開発にMovable Typeを使用することが多々あります。
このアクセルユニバースのホームページにもMovable Typeを使用し運営を行っています。

先日、緊急の時に備えて、ホームページのトップに地震などが起きた際、文言が表示されるようにしたいと依頼がありました。
わかりやすくいいますと、通常時はAのパターン、緊急時はBのパターンという全く違うスタイルを表示したいということです。
本日はその設定方法をご紹介します。

設定方法

私が時間がかかってしまった箇所は、指定した（作成した）ウェブページが公開か非公開かの判定処理です。

実際のソースコード(所々書き換えています)

<mt:SetVarBlock name="blog_id"><$MTBlogID$></mt:SetVarBlock>
<MTIf name="blog_id" eq="1">←ブログIDが「1」だった場合の処理
	<MTPages include_blogs="21" id="公開したいウェブページのブログID">←指定したウェブページが公開だった場合（緊急時の処理）
		<div id="test1">
			<div class="mainBanner">
				<div class="exapmle"><$MTPagebody></div>←指定したウェブページの中身を表示するタグ
			</div>
			<div id="accel"></div>
			<div class="container">
			</div>
		</div>
		<MTElse>←指定したウェブページが非公開だった場合（通常時の処理）
			<div id="test2">
				<div class="mainBanner">
					<div><img src="###" alt="###" width="###"></div>
					<div><img src="###" alt="###" width="###"></div>
					<div><img src="###" alt="###" width="###"></div>
				</div>
				<div id="accel"></div>
				<div class="container">
					<ul>
						<li>
							<a href="javascript:void(0);">
								<img src="###" alt="###">
							</a>
						</li>
						<li>
							<a href="javascript:void(0);">
								<img src="###" alt="###">
							</a>
						</li>
						<li>
							<a href="javascript:void(0);">
								<img src="###" alt="###">
							</a>
						</li>
					</ul>
				</div>
			</div>	
	</MTPages>
</MTIf>

ブログIDで条件分岐するには下記を書かなければいけません。

<mt:SetVarBlock name="blog_id"><$MTBlogID$></mt:SetVarBlock>
<MTIf name="blog_id" eq="1">
ブログIDが1だった場合の処理をここに書く（今回でいうとBのパターンの処理を記載する）
</MTIf>

また

<mt:SetVarBlock name="blog_id"><$MTBlogID$></mt:SetVarBlock>

部分は改行してしまうと動作しないのでご注意ください。
（以前、改行が原因でしたハマりました。）

ブログ作成で大切なこと

多くの人に見てもらえるブログを作成するためには、わかりやすさが大切です。

わかりやすさとは、「必要な情報」が「必要なタイミングで得られる」ことだと考えています。上記の設定は、今回のような緊急時だけではなく、セールの情報など、読み手にとって有益な情報を出し分けることにも利用できます。

このブログが参考になりましたら嬉しいです。

こんにちは。

入社してから、詳細設計書の作成から開発、テスト実施、納品と数多くの経験をして参りました。

ブログラミング未経験の私が、入社から半年経ち大変だと思ったこと、為になったこと
入社前に何を勉強したら良いかわからない人に向けて私が感じたことを書きたいと思います。

【知識不足】
プログラミングを全くやってこなかったため、開発に携わってもその言語の勉強をすることから始めたので、人一倍時間がかかり、満足のいく結果が出せませんでした。
プログラミングをがっつりやりたい方は、時間がある学生のうちに自分が興味のある言語や、アプリの作成をしてみてはどうでしょうか。
私は、HTMLに興味がありましたので、1ヶ月程で取り組めそうな参考書を購入して勉強しました。

【詳細設計の重要さ】
詳細設計というのは、開発に入る前に、基本設計を元に、実際にどのように処理を行ってプログラムを動作させるかを決めていく仕様書になります。
なぜ、この詳細設計が大事なのか。自分がわかるように書くのは駄目だということ。自分が開発をするから、自分が分かれば大丈夫は禁物です。自分が書いた設計書を見ても案件に関わる方全員が理解出来るような設計書を作成しなければなりません。また、設計書を書く時点で疑問点をなくし、スムーズに開発に入ることも詳細設計の重要さの一つです。

【スケジューリングの大切さ】
スケージューリングとは、いくつかのやらなければならない仕事がある時に、どういう順番で進めていけば効率よくできるのかを決めていくことです。
案件には、納期という決められた日付までに全ての作業を終えて、お客様に納品をするという決まりがあります。
まずは、案件で各作業のスケジュールを立てていきます。そのチームで立てたスケジュールに対して個々でスケジュールを立てていきます。
立てたスケジュールに対して、自分の進捗はどうなのか、チームの進捗はどうなのかを毎日MTGの中で共有をします。スケジュールは社内全体で管理しているので、万が一スケジュールが遅れているとその時点でスケジュールを調節しなければなりません。万が一のことがあってからでは遅いので、早め早めにスケージューリングして全体を見通せるようにしなけらばならないのです。

他にも為になったことはいくつもありますが、長くなってしまいますので、今回はこの辺で失礼します。

はじめまして、AUCシステム部の田村です。

業務でサーバー構築を行う際は、AWS等クラウドサービスを利用するのがすっかり当たり前になりました。

新規構築したシステムを配置するため、インスタンスを契約しようとするとき、AWS 料金表を見ていてもどれを選べばよいのかよく悩みます。

AWS 料金表（EC2オンデマンド）

https://aws.amazon.com/jp/ec2/pricing/on-demand/

私がサーバー選びをする際に実施しているポイントや苦労した点について複数回にわたってまとめたいと思います。

サイジングとは？

インターネットで調べてみると、下記のように説明されていました。

サイジングとは、システムやその構成要素について、必要とされる規模や性能を見極めて用意したり、状況に応じて適切な規模に削減あるいは増強を行うこと。
『IT用語辞典 e-Words　http://e-words.jp/w/%E3%82%B5%E3%82%A4%E3%82%B8%E3%83%B3%E3%82%B0.html 』

サイジングの方法

サイジングは、大きく3つの作業に分かれます。

1.利用規模の想定

2. 利用規模を満たすスペックのサーバー選定

3.運用後の値と想定値を比較し、スペックの見直しを行う

利用規模の想定

私は、利用規模を想定するとき下記の観点で、洗い出しを行っています。

コンテンツのデータ量の決定

システムに対して1回アクセスした際に発生するデータの量を決定します。

・1ユーザーがアクセスした際に利用するデータ容量
例えば、WebページならHTMLのファイルサイズ、画像コンテンツの容量などです。

・1ユーザーが登録するデータ（テキスト、画像）の容量

利用数の想定

対象とする母数に対して、何%のユーザーがこのシステムを利用するか、想定します。想定が難しい場合は、何ユーザーまで利用できるようにするか、見込の値を決定します。

・ 1ユーザーが1ヶ月間に平均で登録する回数

・1ユーザーが1ヶ月間に平均で閲覧する回数

システムに必要なデータ量、性能の決定

『コンテンツのデータ量の決定』と『利用数の想定』ができれば、そこから『システムに必要なデータ量、性能』が決定できます。

私はこれをExcelに項目ごとにまとめ、一ヶ月間に必要なスペックを算出しています。

利用規模を満たすスペックのサーバー選定

システムに必要なデータ量、性能が決定したら、いよいよサーバー選定です。

AWS等クラウドサービスの料金表には、どのグレードのサーバーだとどれくらいの性能があるのか項目ごとに詳細に記載されています。これを参考にして、『システムに必要なデータ量、性能』を満たすサーバーを決定していきます。

https://aws.amazon.com/jp/ec2/instance-types/

性能が決定したら、今度は料金の計算です。AWSの場合、Web上で見積を行うツールが無料で公開されています。必要なサーバーをマウスで追加していき、必要な性能を入力すれば、自動的に料金を計算してくれます。

http://calculator.s3.amazonaws.com/index.html?lng=ja_JP

また、見積算出ツール内の『保存して共有』をクリックすれば、専用のURLが発行されるため、簡単に共有することができます。

運用後の値と想定値を比較し、スペックの見直しを行う

実際にサーバーを運用すると、常に想定通りの構成になるとは限りません。実際のデータ量、利用数を測定し、再度『システムに必要なデータ量、性能』を見直します。

AWS等のクラウドサービスは、運用開始後にサーバーの性能を簡単に変更できるところが魅力です。

次回は、1つシステムを想定してサイジングを行って行きたいと思います。