ブログ

  • AIの外側にある、AI活用の本質

    AIの外側にある、AI活用の本質

    
    
    
    
    

    昨今、AI(生成AI、AIエージェント、LLMなど)の使い方に関する情報が溢れていますが、その中には、特定のツールやモデル、そのバージョンに依存した情報も多くあります。

    そのようなツールやモデルの性能に依存するような使い方は、短期的には、そして特定の状況下では役に立つかもしれませんが、新しいツールやモデルが登場することで、それまでの知識やテクニックが通用しなくなることもあるでしょう。

    できるだけ流行に左右されないAI活用術を身に付けたいところですが、その本質は何だろうかと考えた時に、それはAIの外側にあるような気がしています。

    ここでは、仕事を進めていく上で必要になる能力と、それらがAI活用にどうつながっていくかを私なりにまとめていきたいと思います。

    リテラシー

    AIを使用するかどうかに限らず、何かしらのソフトウェアを使う場合、相応のITリテラシーが求められます。個人情報や機密情報、あるいは何かしらのデータを扱う場合は、それらのデータを適切に扱うための情報リテラシーが求められます。

    仕事でAIツールを使用する場合、やり取りの内容が学習に使用されるかどうかや、情報の取扱いに関する設定を確認する必要があります。AIツールに個人情報や機密情報、社外秘に当たる情報を渡す場合は、組織のルールやサービスの利用条件を確認する必要があります。特に、やり取りの内容がAIの学習に使用される場合は、情報の取り扱いに注意が必要です。

    利便性を考えれば、AIに全てのデータを渡してしまった方が便利になるはずですが、リスクが全くないわけではありません。利便性と機密性の観点から、環境に応じて情報を適切に扱う必要があります。

    また、インターネットの情報と同様に、AIの情報も全てが真実とは限りません。AIの場合、間違った情報を堂々と語ることもあり、鵜呑みにするのは危険だということも知っておく必要があります。

    AIエージェントに何かしらの作業をお願いする場合は、実行権限や操作範囲にも配慮する必要があります。AIによって重要なファイルを削除されたり、あるいは内容を書き換えられたり、外部のアクセスによって情報が漏洩したりしないように、十分に注意する必要があります。

    AIを有効活用するためには、情報リテラシーやITリテラシーが必要です。

    チームメンバーとしてのAI

    AIをうまく活用するためのスタンスとしては、AIをチームメンバーの1人として接することが大事だと考えます。

    コミュニケーション

    チームで仕事をするときに最も重要なことは、チーム間のコミュニケーションです。

    • わからないことは確認・質問する
    • 定期的に状況を報告する
    • 状況が変わった時は素早く報告する
    • 注意すべき事があれば事前に連絡する
    • 判断に迷うことがあれば相談する

    これらは、いわゆる「報連相」と言われる社会人の基本です。この基本はどんな仕事をする上でも必要になる重要なスキルです。
    たとえ個人での仕事をしていたとしても、多くの仕事では顧客や上司とのやり取りは発生します。その際、報連相のスキルは必要になります。
    この基本を怠ってしまうと、チームでの仕事をスムーズに進めることは難しいです。コミュニケーションが不足しているチームでは、認識不足によるミスや無駄な作業が増えてしまいます。

    これは、AIと接する場合でも同じです。

    • AIに何かしらの問題解決を手伝ってもらいたい場合、状況をなるべく正確に、具体的に報告することが大事です
    • 知らない知識を教えてもらいたいときは、積極的に質問し、自分の理解が合っているかを確認することで、学習が加速します
    • AIに作業を依頼する場合は、前提知識や制約を事前に連絡しておくことで、無駄な手戻りを減らすことができます
    • 方向性に迷うときは事前に相談することで、意思決定の質を高めることができます

    つまり、AIと接する場合でも、「報連相」を基本とするコミュニケーションを意識することで、AIによるアウトプットの質を高めやすくなります。

    伝え方

    チームで仕事をする際は「報連相」をはじめとするコミュニケーションが大事ですが、積極的にコミュニケーションをとっていたとしても、内容が意図した通り相手に伝わらなければ意味がありません。コミュニケーションでは伝え方も大事です。

    相手にわかりやすく伝えるには、例えば以下のようなことを意識すると効果的です。

    • 結論から伝える
    • 一文を簡潔にして伝える
    • 結論の後に理由・目的・背景を伝える
    • 必要に応じて制約や前提条件などを伝える
    • 相手が持っている前提知識のレベルに合わせて、必要な情報を適宜伝える

    伝え方が下手で相手に意図が伝わらなかった場合、認識に齟齬が生まれ、後々になって手戻りが発生するリスクが高くなり、作業のミスや漏れも発生しやすくなります。そしてこれは、相手がAIだったとしても同じことが言えます。
    伝え方が悪いとAIからのアウトプットが想定と違う結果になってしまう可能性が高まります。

    現状、AIのモデル性能が高くなるにつれて、指示内容が曖昧でもそれなりのアウトプットが出せるようにはなっていますが、それでもまだまだ、使う側の人間の伝え方によってアウトプットの品質が大きく変わる場面は多く見ます。

    相手に対する伝え方を工夫することが、アウトプットの質を高めます。

    部下としてのAI

    AIをチームメンバーとしてだけでなく、優秀な部下として接することができるようになれば、より幅広くAIを活用することができます。

    仕事を任せる

    リーダーやマネージャーのような人をまとめる立場になった場合、いかにして自分の仕事を他のメンバーに任せられるかが重要になってきます。今まで自分でやっていた作業を他のメンバーに任せ、自分自身に時間の余裕をつくり、その上でチーム全体の成果につながる仕事をするのがリーダーやマネージャーの役割です。

    自分自身が慣れている作業の場合、他人に任せるよりも自分でやった方が速い、と思うことはよくあります。
    また、人によっては現状維持の思考が働いてなかなか他人に自分の仕事を委譲できないこともあることでしょう。しかし、リーダーやマネージャーのような、人をまとめる役割を担う人は、なんでも自分でやろうとする思考から脱却し、チームのためになる仕事の時間をどれだけ作れるかが大事になってきます。

    これは、AIを活用するときにも大事な考え方です。
    人間は新しい取り組みをしようとすると、少なからず抵抗が生まれます。慣れている作業であれば、他人やAIに任せるよりも、そのまま自分でやってしまった方が楽だと思うことはよくあります。

    AIは、作業の種類によっては、人間よりも速く、高品質な成果を出せる場合があります。もちろん、使い方次第ではありますが、うまく使えば、慣れた人間がやるよりも素早く高品質に仕事をこなすようになるかもしれません。

    自分の仕事を誰かに任せようとする思考。そして、今よりも良い方法がないかを模索するスタンス。そのようなスタンスになれるかどうかが、AIを活用できるかどうかの差につながります。

    相手に合わせた指示

    これは「伝え方」のセクションで書いた内容と似ている部分もありますが、何かしらの作業を依頼する場合、相手が成果を出しやすくするための工夫が必要です。例えば、仕事の目的やゴール、制約などを適切に伝えることで、多くの場合相手は仕事に取り組みやすくなります。また、作業するために必要な知識に対して、相手がどの程度の前提知識を持っているかによって、伝える情報を取捨選択することが大事です。

    これは、AIに作業を依頼する場合も同じです。ゴールや制約が曖昧なまま作業指示をすると、意図しないアウトプットとなる可能性が高くなります。AIが知識を持っていない領域に対して、必要な情報を渡さないままに指示をしても、満足いく結果にはなりません。

    部下に仕事を振る場合、仕事の内容が同じであっても、相手の性格や持っている知識に合わせて伝える内容や伝え方を変えた方がうまくいきます。AIの場合も、モデルによって持っている知識や推論能力といった性能が変わってきます。相手の特徴を把握した上で、どの情報をどの程度の粒度で渡すべきかを判断しながら指示を出すことで、より良い成果を出すことにつながります。

    成果に対して責任を持つ

    リーダーやマネージャーは、部下やチームメンバーの成果に対して責任を持つ必要があります。AIに仕事を任せたとしても、その成果物に対する人間や組織の責任がなくなるわけではありません。

    例えば、AIにプログラムのコードを作成してもらうとします。
    AIが作成したコードを人間がどこまでレビューするかは、成果物の重要度やリスク、開発組織のルールなどによって変わります。しかし、どのような方法で品質を担保するにしても、成果物に対する責任がAIに移るわけではありません。

    そのため、AIを使って仕事をする場合は、「何かあったときには人間が責任を取って対処できる状態」をいかに作るかが大事になります。ソフトウェア開発の場合は、テストやレビューなど、品質を担保するための工程をどのように実施し、それをどう仕組み化するかが重要になります。

    相手が人間であっても、AIであっても、「指示したことに対する責任を取る」というスタンスでいることが、責任を果たすための仕組みを作ることにつながり、結果として仕事の質を上げることでしょう。

    適材適所なメンバー配置

    チームで仕事をする場合、リーダーやマネージャーは、メンバーの強みや弱み、スキルレベルや性格などを把握した上で、適材適所に仕事を与えていくことが大事です。基本的には、苦手なことをやらせるよりも、それぞれのメンバーの強みを活かした役割分担の方が、チームとしての成果は出やすいでしょう。

    これは、AIにも同じことが言えます。
    先ほど、AIのモデルの特徴によって適切な指示の粒度を判断すると良いと書きましたが、そもそもAIによって得意・不得意などもあります。
    例えば、「ドキュメントの解析や生成」「プログラムの実装」「調査」「画像生成」「定型業務の自動化」など、AIの用途は多岐にわたりますが、AIツールによって、それぞれの強みや実現しやすさなどは変わってきます。

    使用できるAIに複数の選択肢がある場合は、目的に合わせてツールやモデルを適切に選べるようになると、より良い成果につながりやすくなります。

    マネジメント力

    相手に合わせて的確な指示をしたり、成果に対して責任を持ったり、メンバーに応じて適材適所に仕事を振る作業は、マネジメントそのもの。つまり、AIをうまく使いこなすためには、AIに対して適切なマネジメントをすることが大事となります。

    ただし、AIと人間はもちろん同じではないので、全く同じマネジメントが通用するわけではありません。

    AIと人間とで大きく異なるのは、感情の有無です。
    人間は感情があり、それがモチベーションや仕事の質にも影響する場合があります。そのため、人間を相手にマネジメントする場合は、相手の感情や立場などを考慮することが大切です。一方、現在のAIは、人間のような感情やモチベーションを前提にマネジメントする必要はありません。そのため、AIを相手にする場合は感情を気にする必要がなく、その点は人間と比べてマネジメントしやすいポイントとなります。

    一方、何かしらの作業を指示する場合、人間相手であれば詳細まで伝えなくても文脈や状況から色々と察して動いてくれる場合も多いですが、AIはそのような文脈を察してくれないことが多くあります。そのため、人間相手の場合よりも詳細で的確な指示が必要になる場合もあります。

    人間とAIではそれぞれマネジメントの難しさがありますが、いずれにしても、相手のことをよく理解し、環境に合わせて適切なマネジメントをすることが大事であることには変わりありません。

    教師としてのAI

    ここまでは、人間がAIに指示を出し、仕事を任せる立場としての話をしてきました。しかし、AIとの関係は一方通行ではありません。人間がAIから学ぶことで、さらにAIを活用する能力を高めることができます。

    イメージ力と言語化力

    生成AIを効果的に使うには、イメージ力と言語化能力が大事です。

    ゴールややりたいことが明確にイメージできていて、それを具体的に言語化して伝えることができれば、AIはきっとうまく働いてくれます。一方で、ゴールややりたいことが曖昧であったり、イメージを言語化することができない場合は、AIがどれだけ優秀でも、思い描いたアウトプットには繋がらないケースが多いはずです。

    例えば、 AIを使ってWebサイトを作る場合を考えます。
    今のAIの性能で考えると、「いい感じのWebサイト作って!」くらいの指示でも、それなりの見栄えのサイトを作ってくれることでしょう。
    しかし、思い描いているイメージがある場合、そのような曖昧な指示だけでイメージと一致するWebサイトが出来上がる確率はとても低いです。
    ある程度具体的なイメージがあるのであれば、それを言語化して伝えることが大事です。

    Webサイトの場合、UIを作るためのコンポーネント(部品)として、例えば以下のようなものがあります。

    • カルーセル(スライダー)
    • アコーディオン
    • モーダルウィンドウ(ダイアログ)
    • ページネーション
    • パンくずリスト

    などなど。このような、Webサイトを構成するための部品の名前を多く知っていれば、それだけ言語化がしやすくなり、AIのアウトプットと自分自身のイメージとの差分が少なくなります。しかし、そもそもこのような用語を知らない場合、イメージを具体的に言語化して伝えるのは難しく、やり取りを何度繰り返しても、思い通りのアウトプットにならないかもしれません。

    学ぶ力

    AIを教師として活用することで、自分自身のイメージ力と言語化力を高めることができます。AIは幅広い分野について豊富な知識を持っており、質問すればとても分かりやすく、かつ何度聞いても機嫌を悪くすることもなく教えてくれます。最近では、図を書いてくれたり、動画を作ってくれたり、HTMLでWebページを作って分かりやすく教えてくれたりもします。自分自身が生徒になって質問上手になることで、自分自身がスキルアップしながら、AIのアウトプットの質も高めることができるようになるでしょう。

    また、AIを使用する際にイメージが具体化できていない場合に、AIの協力を借りてイメージを強化する使い方もまた、AIを教師と見立てた有効な使い方と言えるでしょう。

    仕事でAIを使う場合、学習にばかり時間をかけることはできないケースももちろんあるでしょう。しかし、知らないことを知らないままにしておくよりは、その都度自分自身の知識を増やしながら仕事を進める方が長期的には良い成果につながるはずです。

    「AIを使って学びを得るためのスキル」が、結果としてAIによるアウトプットの質を高めます。

    プログラミング的思考と仕組み化

    ここまでは、主にAIとの関わり方や、個々の作業で成果を出すための考え方を紹介してきました。これらの考え方を意識することで、AIを使うタイミングやプロンプトのコツをつかみやすくなり、アウトプットの精度を上げやすくなるかと思います。

    しかし、毎回プロンプトに丁寧な長文を入力しながらAIとやり取りしていると、プロンプト作成にそれなりの時間がかかります。毎回、長く丁寧なプロンプトを入力しなくても、アウトプットの質を安定させることができるようになると便利です。

    設定ファイルによるルールの追加

    設定ファイルや「スキル」と呼ばれる機能をうまく使うことで、プロンプトの入力をシンプルにしながらアウトプットの精度を高められるようになり、結果的に作業効率が上がります。

    プロンプトを作成する際に毎回入力するような内容、あるいは前提条件としてAIに常に意識しておいてほしい情報などがあれば、設定ファイルを作成し、その中に必要な情報を追記します。設定ファイルは、多くのAIツールでファイル名が決められており、mdファイル形式で指定されることが多いです。このような設定ファイルを用意して前提条件や制約を書いておくことで、個々のプロンプトの入力を簡潔にしやすくなります。

    例えば、ソースコードのレビューやブログ記事のレビューのような、レビュー作業をAIに依頼するとします。この時、レビュー観点を毎回プロンプトに細かく入力するのは手間です。レビューするときには漏れなくこの観点を入れてほしい、という内容があれば、それを設定ファイルなどにまとめて作業時にその設定ファイルを読み込むようにしておくことで、個々のプロンプトを簡潔にできます。

    繰り返しの作業を効率化する「スキル」

    特定の作業をお願いする場合に、毎回似たような細かい指示文を書いている場合は、それを「スキル」という形で定義することで、毎回の指示を省略できるようになります。

    例えば、「Javaで書いたプログラムをPythonに変換したい」のような要望があったとします。この時、どのようなルールで変換し、変換した結果にエラーがないことをどう検証し、実行結果が変わらないことをどう検証し、ドキュメントをどう作っていくか、などを決める必要があります。このような作業の手順を、スキルとして定義しておけば、毎回細かく指示を出さなくても、一定の手順やルールに沿って作業を進めやすくなります。

    繰り返し行う作業で、作業の手順やルールが明確に決められる、かつ毎回プロンプトで細かく指示を出すのは面倒、という作業があれば、それをスキルに落とし込むことで作業を大きく効率化することができます。

    スキルをうまく使うには、業務の中で繰り返しの作業になっている箇所を見つけ出すための抽象化の能力が必要になってきます。

    プログラミング的思考

    この「スキル」は自分で作成できるほか、公開されているものを利用することもできます。

    プログラミングをするときは、似たようなコードがあればそれを関数やクラスにして共通利用できる形にすることで、効率よく開発を進めることができるようになります。また、すべてを自分で作らずとも、既存のライブラリやフレームワークを活用することで、より効率よく開発ができるようになります。

    そういう観点では、効率よくプログラミングするための考え方と、効率よくAIを活用する考え方は似ています。

    さらに、AIの活用においては、指示を共通化するだけでなく、AIがうまく仕事を進められるような仕組みそのものを作る、という考え方もあります。

    そのような考え方は「ハーネスエンジニアリング」と呼ばれています。これは、AIエージェントに適切な情報やツールを提供し、作業結果を検証したり、失敗した場合に修正できるようにしたりと、AIが安定して仕事を進められる環境を設計する考え方です。

    例えば、AIにプログラムの実装を任せる場合、コーディング規約を守るように指示するだけでなく、静的解析や自動テストを実行し、問題があればAIがその結果を確認して修正できる仕組みを作る、といった方法が考えられます。

    このように、AIに対する指示の出し方を工夫するだけでなく、AIが安定して成果を出せるような仕組みを作ることも、AIを有効活用するための重要な能力になってきます。

    そのためには、作業の手順を整理したり、繰り返しの処理を共通化したり、処理の結果を検証する方法を考えたりといった、プログラミングやシステム設計で培ってきた問題解決力や仕組みを作る考え方が役に立ちます。

    業務フローの分析と設計

    ここまで、プロンプトの精度を上げるためのスタンスや、設定ファイルやスキルを使った「再利用」による効率化の考え方についてまとめました。

    これらを意識することで、個々の作業に対してはAIをうまく使って作業効率や品質を上げやすくなるかと思います。しかし、そもそもの業務の目的が曖昧だったり、業務フローそのものに大きなボトルネックがある場合は、いくらAIの使い方が上手くなったとしても、仕事全体を通しての効率化や成果の拡大にはつながらないかもしれません。

    実際、「AIを導入したけれど仕事の効率はあまり上がっていない」とか、「AIを導入して個々の作業効率は上がったけれど売上は変わらない」などの声をよく耳にします。これらの要因の1つとしてボトルネックを解消できていないことが考えられます。

    例えば、ソフトウェア開発の場合、AIを導入することでコーディングのスピードを大幅に上げることができます。しかし、そのコードを人間がレビューする場合、レビュー待ちの作業が積み上がり、リリースまでの時間が期待したほど短縮されない可能性があります。

    また、開発における契約形態によっては、開発に着手するまでに多くの時間がかかるケースもあります。顧客に見積もりを提出した後、その見積もりに対する承認フローに時間がかかると、契約までに多くの時間を要するため、AIを使って開発をしたとしても、見積もりからリリースまでの時間はあまり短くならないというケースもあります。

    コードレビューの場合は、先ほど紹介した「スキル」やハーネスエンジニアリングによって比較的解消しやすい部分ですが、承認フローのような業務の場合、AIを使ったところでどうにもならないケースも多いです。特に、「顧客の承認フロー」のように、自分たちでコントロールが利かない箇所のボトルネックに対しては、自社でAIを導入してもボトルネックの解消は難しいです。

    AIをどれだけ有効に活用しても、効果があまり得られていない場合は、業務フローそのものを見直す必要があるのかもしれません。AIの導入によって個々の作業を効率化するだけでなく、業務フロー全体を見直し、ボトルネックを継続的に改善していく。そのような取り組みによって、AIによる効果を、仕事全体の成果につなげやすくなるのでしょう。

    真の意味でAIを活用する(AIで業務全体を効率化し、売上などの成果を上げる)には、業務分析と業務設計をする能力が必要になってきます。

    まとめ

    ここまでに書いてきたAIを活用するためのスキルをざっくりまとめてみます。

    • リテラシー(情報リテラシー、ITリテラシー)
    • コミュニケーション(報連相、質問、確認)
    • 伝え方
    • マネジメント力
    • イメージ力と言語化力
    • 学び方
    • 抽象化能力(再利用性を見つける力)
    • プログラミング的思考
    • 仕組み化
    • 業務設計力

    こうやって箇条書きされた内容をみると、AIを使うかどうかに関係なく、エンジニアとして、あるいはリーダー・マネージャーとして成果を出すために求められるスキルばかりです。

    結局のところ、「AIを活用するためのスキル」は、「仕事で成果を出すためのスキル」に集約されるのかもしれません。AIを活用するために、AIについて知ることは大事です。しかし、そもそもチームや組織の中で成果を出すためのスキルがなければ、AIの使い方だけを学んでも、結果的に効率化や大きな成果には繋がらないかもしれません。

    AIを使いこなすために、人間自身が仕事のスキルを磨く。そして、AIを活用することで、人間自身のスキルも高めていく。AIの進化に合わせて新しいツールや使い方を学ぶことも大事ですが、それと同時に、仕事で成果を出すための普遍的なスキルを磨き続けることも大事なのだと思います。

  • AI-DLC で社内ツールを作ってみた ― AI に「質問される」開発の良かったこと・課題に感じたこと

    AI-DLC で社内ツールを作ってみた ― AI に「質問される」開発の良かったこと・課題に感じたこと

    はじめに

    執筆時点で、このブログの記事は53本ありました。

    記事が増えてくると、書き手が「自分の記事が検索でどう伸びているか」を知る手段がほしくなります。

    そこで Google Search Console(以下 GSC)のデータから伸びている記事を抽出し、定期的に Slack に通知する仕組みを作りました。

    今回の開発では、AWS が提唱する AI-DLC(AI-Driven Development Life Cycle) というやり方を試しました。

    本記事では、作ったツールの技術解説よりも、AI-DLC という進め方を実際に使ってみて よかったこと と 課題に感じたこと を中心に紹介します。

    この記事の要点

    • ✅ Inception(要件定義)から Operation(デプロイ)まで、1つのワークフローで進められる
    • ✅ AI が questions file(選択式の質問)で要件を詰め、回答どうしの矛盾まで指摘してくれる
    • ✅ reviewer(レビュー役のエージェント)が、設計やコードの穴を見つけてくれる
    • ✅ 判断の経緯が記録に残り、途中でAI コーディングツールを替えても続きから進められる
    • ⚠️ 小さなツールには、成果物と手続きが重い
    • ⚠️ reviewer の指摘を残したまま Approve すると、後のステージにしわ寄せが来る
    • ⚠️ AI の推論が、確かめられないまま learnings(学び)として残ることがある

    AI-DLC とは

    AI-DLC は、AWS が2025年7月に発表したソフトウェア開発の方法論です。

    これまでの AI 活用は「人が作業を主導し、AI が補助する」形が中心でした。

    AI-DLC では主従を逆にして、AI が計画を立て、不明点を人に質問し、成果物を作る。人は成果物を確認して承認する、というサイクルをステージごとに繰り返します。

    AI-DLC は、AI コーディングツール向けのルール一式として GitHub で公開されています(awslabs/aidlc-workflows)。

    ルールを読み込んで動かす AI コーディングツールのことを ハーネス(harness) と呼び、Claude Code、Kiro、Codex CLI、Cursor、GitHub Copilot などに対応しています。

    今回は v2.5.64(執筆時点の最新は 2.10.0)を使い、ハーネスとして Claude Code と Codex を併用 しました。

    全体の構成

    v2.5.64 では、ワークフロー全体が5つのフェーズ・32のステージに分かれています。

    • Initialization(3ステージ):始める準備。作業場所を用意し、既存コードの有無を判定して、進捗を記録する状態ファイルを作る
    • Ideation(7ステージ):何を・なぜ作るかを固める。実装の話に入る前に、狙いの整理や市場調査、実現できるかの検討を行う
    • Inception(8ステージ):どう作るかを決める。チームのプラクティス、要件、画面、設計、作業の分け方と順番を決める
    • Construction(7ステージ):実際に作る。詳細な設計、コードの生成、テスト、CI の整備を行う
    • Operation(7ステージ):動かして運用する。デプロイ、監視、障害対応、運用で得た結果からの改善を行う

    1つのステージの中は、おおむね次の流れで進みます。

    ① AI が questions file(選択式の質問)を作る
          ↓  人が [Answer]: 欄に回答する
    ② AI が成果物(要件書・設計書・コードなど)を作る
          ↓
    ③ reviewer が成果物をレビューする(ステージによる)
          ↓
    ④ 人が approval gate で Approve か Request Changes を選ぶ
          ↓  Approve されたら
       次のステージへ

    本記事で出てくる AI-DLC の用語を整理しておきます。

    • スコープ(scope):実行するステージと省略するステージの組み合わせ。既製のもの(bugfix・feature など)のほか、案件に合わせて作ることもできる
    • composer:依頼内容とリポジトリの状態から、案件に合わせたスコープを提案するエージェント
    • depth:各ステージでどこまで詳しく検討するかの設定(Minimal / Standard / Comprehensive)
    • questions file:AI が作る選択式の質問ファイル。[Answer]: 欄に回答する
    • reviewer:成果物を作ったエージェントとは別に、成果物をレビューするエージェント。READY / NOT-READY で判定する
    • approval gate:各ステージの最後で、人が Approve するまで次に進まない関門
    • audit log:回答・Approve・Request Changes・レビュー結果などの記録
    • observation diary:ステージごとの AI の作業記録(memory.md)。AI の解釈・逸脱・トレードオフ・未解決の疑問を記録する
    • learnings:ステージの終わりに AI が挙げる教訓の候補。人が選んだものが project.md などに追記され、以降のステージで参照される

    今回作ったもの

    GSC のデータを定期的に集計し、前週と比べて検索で伸びている記事を社内の Slack に投稿するツールです。アプリケーションコードは約1,000行の小さなものですが、扱う技術は多岐にわたります。

    • アプリケーション:Python
    • 実行環境(AWS):Lambda、EventBridge Scheduler(定期実行)、Secrets Manager、IAM、CloudWatch Logs
    • インフラのコード化:Terraform(state は S3 で管理)
    • 外部サービス:Google Search Console API、Slack(Incoming Webhook)
    • CI:GitHub Actions(Lint・テスト・Terraform の検証・デプロイ用パッケージの作成)

    要件定義からデプロイ手順の作成まで、AI-DLC のワークフローに沿ってステージを順に進めました。
    上に挙げたアプリケーションのコード、Terraform、CI の設定、デプロイ手順書は、すべて AI がワークフローの中で作ったものです(進めたステージは次の「スコープ」で紹介します)。
    デプロイの実行だけは、AI が作った手順書に沿って人が行っています。

    スコープ:32ステージのうち11ステージを実行

    AI-DLC では、32のステージをすべて実行する必要はなく、案件に合わせて選べます。
    今回は composer(スコープを提案するエージェント)が「11ステージを実行する」スコープを提案してきたので、私が承認しました。

    実行したステージは次のとおりです(最初の Initialization の3ステージは自動で終わるので、一覧には載せていません)。

    • Inception
      • practices-discovery:チームの開発ルールを決める
      • requirements-analysis:要件を整理する
      • refined-mockups:Slack 通知の見た目を決める
      • application-design:アプリケーションを設計する
    • Construction
      • code-generation:コードを書く
      • build-and-test:ビルドとテストを行う
      • ci-pipeline:CI を整える
    • Operation
      • deployment-execution:デプロイする(今回は手順書の作成まで)

    composer は、作るものが依頼の時点で決まっていたことから、Ideation をまるごと省略していました。

    よかったこと

    1. Inception から Operation まで、1つのワークフローで進められる

    前のステージで AI が見つけた課題を、後のステージで拾って解決していきます。

    • build-and-test ステージで、AI が「Lambda に載せる zip を作る手順がない」と書き残しました。すると次の ci-pipeline ステージで、zip を作るスクリプトが作られました。
    • deployment-execution ステージでは、スクリプトが出力する zip のファイル名と、Terraform が参照するファイル名の食い違いを AI が見つけて直しました。直さなければデプロイが失敗していました。

    2. 回答どうしの矛盾を見つけて、追加で質問してくる

    AI は questions file の回答を1問ずつ見るだけでなく、組み合わせたときに問題がないか まで確認してきます。

    requirements-analysis ステージで、私は「順位が大きく上がった記事から上位10本を載せる」「表示回数がごく少ない記事も対象に含める」と答えていました。

    すると AI は、表示回数が少ない記事ほど順位が大きく動くことを数字の例で示し、今の回答のままでは 上位10枠のほとんどが、ほぼ誰にも見られていない記事で埋まる と指摘してきました。

    3. reviewer が、設計やコードの穴を見つける

    いくつかのステージでは、成果物を作るエージェントとは別に、reviewer が成果物をレビューします。

    今回 reviewer がついた4ステージは、すべて初回の判定が NOT-READY(まだ承認できる状態ではない) でした。

    なお今回のレビューは advisory(助言)の扱いで、Approve するかどうかは人が決めます。

    • requirements-analysis:比較に使う前週のデータが取れなかった場合に、同時に当てはまる2つの要件のどちらを優先するかが決まっていない
    • refined-mockups:通知を「新しい検索語で見つかり始めた記事」と「検索順位が上がった記事」の2つの一覧に分ける設計で、両方に当てはまる記事をどちらに載せるかが決まっていない
    • application-design:必ずテストすると決めていたケース(前週のデータが取れなかった場合)で、通知に出すはずの記事一覧を、設計したデータ構造では受け渡せない(Critical)
    • code-generation:設定次第で通知に載る記事数が上限を超える、取得するデータが多いと続きのページを取りにいかない など

    特に application-design の指摘は、コードを書いた後に気づくと手戻りが大きい問題です。reviewer は、コードを書く前の段階で見つけていました。

    4. 判断の経緯が残る

    AI-DLC は、決まったことだけでなく 採用しなかったこと も記録します。

    practices-discovery ステージでは、quality・developer・devsecops の各エージェントがそれぞれ推奨を出しました。「テストカバレッジ80%以上」など、私が選ばずに採用しなかった推奨もあります。採用しなかった推奨も、どのエージェントがどんな根拠で出したかとあわせて、evidence.md(判断の根拠をまとめたファイル)に残っています。

    さらに、各ステージの observation diary(AI の作業記録)には、AI が作業中に行った解釈やトレードオフ、未解決の疑問が残ります。後から参加した人でも経緯を追えます。本記事も、AI-DLC が残した記録をもとに書いています。

    5. 途中でハーネスを替えても、続きから進められる

    AI-DLC は、どのステージまで進んだか、何が決まったかを、すべてリポジトリ内のファイルに保存します。中断しても、ハーネスを替えても、ファイルを読み込めば続きから進められます。

    今回の開発では何度か、Claude Code の利用上限に達しました。上限に達した後、Codex に「AI-DLCの続きをお願いします」と指示し、Codex で実装の続きを進め、reviewer のレビューを経て Approve まで終えました。

    6. できなかったことを「できた」と書かない

    deployment-execution ステージでは、手元の AWS 認証情報が期限切れだったため、AI はデプロイを実行できませんでした。

    AI は実行できなかったことを記録し、成果物の冒頭にも「デプロイは未実施で、実行できる状態にした記録である」と明記しました。

    後日、私がデプロイを済ませて完了を伝えたときも、AI は結果を見せていない確認項目を合格扱いにしませんでした。

    7. learnings が後のステージに効く

    ステージの終わりに、AI が learnings(次に活かす教訓)の候補を挙げ、私が残すものを選びます。

    選んだ learnings は project.md(プロジェクト固有のルールをまとめたファイル)に追記され、以降のステージで参照されます。今回は9件を残しました。

    例えば refined-mockups ステージで、「後のステージで要件の振る舞いを変えたら、要件書に反映するか相互参照を入れる」という learning を残しました。

    次の application-design ステージでは、設計の変更で画面設計の資料が古くなっていました。

    変更は設計書にしか書かれておらず、reviewer は残した learning を根拠に、画面設計の資料にも反映するよう指摘しています。

    課題に感じたこと

    1. 小さなツールには成果物が重い

    アプリケーションコードは約1,000行ですが、AI-DLC が作った成果物は、questions file などの記録も含めて Markdown 49ファイル・約23万字 になりました。

    要件書(requirements.md)だけで約1万6千字あります。

    本来は、成果物を読んでから Approve する必要があります。

    今回の規模のツールには重い量でした。

    小さな案件では、ステージをさらに削るか、depth(検討の詳しさ)を今回の Standard より下げることを検討したほうがよいと思います。

    2. サブスクリプションの利用上限に2回達した

    Claude Code と Codex は、どちらもサブスクリプションの枠内で使っており、月額以外の費用はかかっていません。

    ただし「よかったこと5」で書いたとおり、Claude Code の利用上限に何度か達しています。

    AI-DLC は、ルールや前のステージの成果物を読み込みながら進むため、使用量が多くなります。

    audit log を見ると、1つのステージで数千万トークンを読み込んでいました(大半はキャッシュからの読み込み)。

    今回は Codex に切り替えて続けられましたが、1つのハーネスしか使えない場合は、上限が戻るまで待つことになります。

    3. エンジンのチェックが厳しく、手続きで足止めされる

    AI-DLC のエンジン(ワークフローの進行や記録を管理するツール群)は、記録の食い違いを防ぐため、手順から外れた操作を機械的に拒否します。

    例えば、人が回答の要約を確認した後に questions file が書き換わると、「確認をやり直す必要がある」として先に進めなくなります。

    どれも「人が確認していない内容で先に進まない」ための仕組みで、趣旨は理解できます。

    ただ今回、拒否は11件記録され、うち7件が refined-mockups ステージに集中しました。

    修正するたびに要約の再確認と reviewer の再レビューが必要になり、往復が続きました。

    4. reviewer の指摘を残したまま Approve すると、後のステージにしわ寄せが来る

    requirements-analysis ステージで reviewer が Major の指摘を3件出していましたが、私は反映しないまま Approve しました。

    結局、指摘は後のステージで解決することになり、要件書も遡って直しています。

    5. 決めたプラクティスと実際の運用がずれていく

    practices-discovery ステージで「main に直接コミット」と「CI が落ちたらマージ不可」を両方選んだところ、AI に矛盾を指摘され、いったん PR 方式に決めました。

    後からチームのルールを main への直接コミットに変えましたが、プラクティスを記録した team.md は PR 方式のまま残っています。

    ルールを変えたときは、AI-DLC の記録も人が更新する必要があります。

    6. AI の推論が、確かめられないまま learnings として残ることがある

    deployment-execution ステージで、AI は「GSC からデータを取得するサイトの指定を誤ると、エラーにはならず『データ0件』が返ってくるため、設定の誤りに気づきにくい」と書いていました。

    私は、AI の書いた内容を例に含む learning を、Approve と同時に project.md に残しています。

    記事を書くにあたって実際に API を呼んで確かめたところ、サイトの指定を誤るとエラー(403)が返り、「データ0件」にはなりませんでした。

    ツールも 403 を受け取ると「取得に失敗した」と Slack に通知するため、誤りには気づけます。

    AI のもっともらしい推論が、確かめられないまま learnings に残っていたことになります。

    learnings は人が選んで残す仕組みですが、選ぶときに中身の正しさまで確かめなければ、誤った推論がルールとして残ってしまいます。

    7. AI が肩代わりできない準備がある

    Google Cloud や Slack 側の設定、AWS の認証情報の更新といった外部サービス側の準備は、人がやる必要があります。

    AI-DLC 自体の導入にも、いくつか手間がありました。

    • bun(フックやツールの実行環境)のインストールが必要
    • 同梱の設定ファイルは AWS Bedrock 経由での利用が前提になっており、Bedrock を使わない今回は設定を書き換える必要があった
    • 導入時に .gitignore の設定が不十分で、AI-DLC の不要なファイルが Git の管理下に入ってしまい、後から整理した

    使ってみての所感:向いている案件・向いていない案件

    向いている案件

    • 要件に曖昧さが残っていて、詰めながら進めたい
    • 外部 API・認証・インフラなど、判断の多い境界がある
    • 後から別の人が引き継ぐ、判断の経緯を残したい

    向いていない案件

    • 仕様が明確で、とにかく早く作りたい
    • 使い捨ての検証(PoC)
    • AI が作った成果物を読む時間が取れない(中身を確かめないまま Approve することになる)

    使うときのコツも挙げておきます。

    • スコープでステージを絞る:全ステージを回す必要はありません。
    • reviewer の指摘は Approve 前に潰す:先送りした判断は、後のステージで片付けることになります。
    • AI の推論は、learnings として残す前に確かめる:実際に確かめた事実か、AI の推論かを見分けます。
    • 迷ったら、選ばずに聞き返す:ci-pipeline ステージで「CI は GitHub Actions でよいか」と聞かれた際、選択肢を選ばずに「CodePipelineの方がよかったりする?」と聞き返したところ、AI は両者を比べ、根拠を添えて推奨を示してくれました。
    • 複数のハーネスを使える状態にしておく:利用上限に達しても、ハーネスを替えて続きから進められます。

    おわりに

    AI-DLC を使うと、AI は Inception から Operation まで、決めるべきことを質問し、回答の矛盾を指摘し、経緯を記録してくれました。

    一方で、成果物と approval gate の手続きは重く、記録が増えるほど、中身を人が確かめる責任も増えます。

    小さなツールには重いところもありますが、要件に曖昧さがある案件や、判断の経緯をチームで残したい案件では、試してみる価値があると考えています。

    (ちなみに作成した通知ツールはデプロイして実際に稼働中です)

    参考資料

  • フロントエンド開発でつまずきやすいポイントと解決方法

    WebサイトやWebシステムの開発では、HTML、CSS、JavaScriptなどのフロントエンド技術が欠かせません。実際に開発を進めていくと、「書き方は合っているはずなのに画面が思った通りにならない」「JavaScriptが動かない」「CSSを変更したら別の場所まで崩れてしまった」といった問題に直面することがあります。
    こうした問題は、単純な文法ミスだけが原因とは限りません。HTMLの構造、CSSの適用範囲、JavaScriptが処理を実行するタイミングなど、複数の要因が関係している場合があります。
    本記事では、フロントエンド開発で特につまずきやすいポイントと、その原因を調査する際に意識したいことについて解説します。

    1. HTMLは「見た目」ではなく「構造」を意識する


    HTMLを記述する時に重要なのは、画面上でどのように見えるかだけではなく、HTMLがどのような構造になっているかを意識することです。
    例えば複数のdivが入れ子になっている場合、変更したい要素がどの親要素に属しているのかを把握する必要があります。開始タグと終了タグの位置を見誤ると、レイアウト崩れの原因になることがあります。
    そのため、HTMLを修正する際にはインデントを整え、親子関係を分かりやすくしておくことが重要です。
    また、Thymeleafなどのテンプレートエンジンを使用している場合は、条件分岐や繰り返し処理といった部分も確認する必要があります。例えば、条件に応じた表示・非表示、リストの内容の繰り返し表示などの処理が複数組み合わさっている場合は、「どの条件で、どの要素が表示されるのか」を整理して確認すると、問題の原因を見つけやすくなります。

    2. CSSが効かない時は「優先順位」を確認する


    CSSの修正でよくある問題が、「CSSを書いたのに反映されない」というものです。
    この場合、記述そのものが間違っているとは限りません。同じ要素に複数のスタイルが指定されている場合、それぞれの記述方法などによってどの指定が優先されるかが決まります。
    CSSが反映されない時は、ブラウザの開発者ツールを使用して、対象の要素にどのCSSが適用されているのかを確認しましょう。
    特に、自分が記述したCSSに打ち消し線が付いていないかを確認することがポイントです。打ち消し線が付いている場合は、別のCSSによって上書きされている可能性があります。
    また、どうしてもCSSが効かない時は!importantを追加すれば良いと考える人がいます。しかし、!importantを多用するとメンテナンス性が下がり、優先順位を考えての修正がしづらくなってしまいます。まずは「なぜそのCSSが適用されていないのか」を確認することが大切です。

    優先順位イメージ

    3. CSSの変更では「影響範囲」に注意する


    既存システムのCSSを修正する時には、その変更が他の画面に影響しないかどうかも考える必要があります。
    例えば、複数の画面で使用されている共通クラスを変更すると、そのクラスを使用している全ての要素の表示が変わる可能性があります。
    そのため、特定の画面だけに変更を適用したい場合は、画面専用のクラスを用意するなど、影響範囲を限定することが重要になってきます。
    「修正した画面では正しく表示されたから問題ない」と判断するのではなく、同じクラスやCSSを使用している他の画面についても、クラス名を全体検索するなどして確認しましょう。

    4. JavaScriptが動かない時は「実行タイミング」を確認する


    JavaScriptでは、「コード自体は間違っていないのに動かない」という問題がよく発生します。
    原因の一つとして考えられるのが、JavaScriptを実行するタイミングです。
    例えば、JavaScriptでHTML上のボタンを取得してイベントを設定する場合、JavaScriptを読み込んだ時点で対象のボタンが存在していなければ、正しく処理を設定できません。
    また、JavaScriptが動作しない場合は、ブラウザの開発者ツールにあるコンソールを確認することも重要です。
    エラーが表示されている場合は、エラーの内容やファイル名、行番号を確認することで原因となっている箇所を絞り込むことができます。
    「JavaScriptが動かない」という結果だけを見るのではなく、「処理のどの段階で止まっているのか」を確認することが効率的な原因調査につながります。

    5. 「画面に表示されない」時は原因を分けて考える


    フロントエンドの不具合を調査する時は、問題を一度に解決しようとせず、HTML、CSS、JavaScriptの3つに分けて考えると整理しやすくなります。
    例えば、「ボタンが表示されない」という問題が発生した場合、まずHTML上に本当にボタンの要素が存在するのかを確認します。
    HTMLに存在しているのであれば、次にCSSを確認します。display: noneなどによって非表示になっていないか、サイズや位置に問題がないかを確認します。
    HTMLとCSSに問題がなければ、JavaScriptによって表示・非表示が切り替えられていないかを確認します。
    このように原因を切り分けることで、「とりあえずCSSを変更する」「JavaScriptを追加してみる」といった手当たり次第の修正を避けることができます。

    6. 開発者ツールを活用する


    フロントエンドの問題を効率的に調査するために、ブラウザの開発者ツールは非常に役立ちます。
    機能としては、HTMLやCSSを確認できる「要素」、JavaScriptのエラーやログを確認できる「コンソール」、サーバーとの通信内容を確認できる「ネットワーク」等があります。
    例えば、ボタンを押しても何も起こらない場合は、コンソールにJavaScriptのエラーが出ていないか確認できます。サーバーとの通信が関係している場合は、ネットワークを確認することでリクエストが送信されているか、どのようなレスポンスが返ってきているかを確認できます。
    ソースコードだけを見るのではなく、実際にブラウザ上で何が起こっているのかを確認することがフロントエンド開発では重要です。

    7. フロントエンドとバックエンドのつながりを意識する


    Webシステムでは、フロントエンドだけで処理が完結しているとは限りません。
    例えば、Javaなどのバックエンドでデータを取得し、そのデータをHTMLに渡して画面に表示する場合があります。
    画面に表示される値がおかしい場合、HTMLだけを確認しても原因が分からないことがあります。その場合は、ControllerやService、データベースからの取得処理など、バックエンド側まで確認する必要があります。
    反対に、バックエンドで正しい値が取得できていても、HTMLやJavaScript側に問題があれば画面には正しく表示されません。
    そのため、フロントエンドを効率的に調査するには、「データがどこで作られ、どのような処理を経て画面に表示されているのか」という一連の流れを理解することが重要になってきます。

    まとめ


    HTML、CSS、JavaScriptを使用したフロントエンド開発では、それぞれの文法を覚えるだけではなく、3つの技術がどのように連携しているのかを理解することが重要です。
    HTMLでは画面の構造、CSSでは適用範囲や優先順位、JavaScriptではイベントや実行タイミングを意識することで、問題が発生した際にも原因を整理しやすくなります。
    また、既存システムの改修では、一つの変更が別の画面や機能に影響する可能性があります。そのため、修正箇所だけを見るのではなく、開発者ツールなどを活用して影響範囲や処理の流れを確認することが大切です。
    フロントエンドで問題が発生した際には、その場限りの修正ではなく、「どこで問題が発生しているのか」「なぜその問題が発生しているのか」を順番に切り分けることを意識しましょう。

  • ChatGPTの設定、初期値のままで大丈夫?回答がどう変わるのか試してみた

    ChatGPTの設定、初期値のままで大丈夫?回答がどう変わるのか試してみた

    ※本記事は2026年8月時点のChatGPTをもとにしています。プランや利用環境によって、表示される設定項目が異なる場合があります。

    はじめに

     みなさんはChatGPTの「設定」を開いたことがありますか?
    ChatGPTに同じ質問をしているはずなのに、人によって「便利」「使いにくい」と評価が分かれることがあります。
    もちろん質問の仕方も影響しますが、実はその前に、ChatGPTの「設定」が違っているかもしれません。
    一部の設定を確認したことはあっても、すべての項目に目を通した人は、あまり多くないのではないでしょうか。
    ところが現在のChatGPTには、

    • ChatGPTの話し方を変える
    • 自分について覚えてもらう
    • 過去の会話を今後の回答に反映させる
    • 回答の仕方をあらかじめ指定する
    • データの利用方法を設定する

    など、意外と重要な設定や、試してみると面白い設定があります。
    つまり、同じChatGPTを使っていても、設定次第で使い勝手が結構変わるわけです。
    そこで今回は、ChatGPTの主な設定を確認しながら、
    「この設定で、いったい何が変わるの?」
    というところまで実際に見ていきます。
    目標は、この記事を読み終わったあとに一度だけでも設定画面を開いてもらうことです。
    主な設定を一通り確認したうえで、「ここだけは確認してほしい」と感じた4項目をまとめたので、これまで設定をあまり意識していなかった方は、ぜひこの機会に確認してみてください。

    「パーソナライズ」

     個人的に一番面白いと思ったのが「パーソナライズ」です。
    ChatGPTでは、回答するときの「基本のスタイルとトーン」を変更できます。

    たとえば、フレンドリーな話し方、批判的な話し方、プロフェッショナルな話し方などです。
    OpenAIによると、この設定で変わるのは主に回答のスタイルやトーンであり、ChatGPTそのものの能力や安全上のルールが変わるわけではありません。
    つまり、頭脳を入れ替えるのではなく、受け答えの雰囲気を着替えさせる設定です。
    実際に同じ質問をして比較してみました。

    質問:「次回の社員旅行は世界一周旅行にしようと思ってます。どう思う?」
    回答:
    ①フレンドリーで温かみ多め

     めちゃくちゃ夢はあります。社員旅行の「次どこ行く?」に対する答えとして、いきなり世界一周は強すぎます(笑)。
    もし本気で世界一周社員旅行を成立させるなら、30人想定で費用・必要日数・ルートまで現実的に試算できます。たぶん数字を出すと一気に面白くなります。

    ②プロフェショナルで温かみデフォルト

     企画としてはめちゃくちゃ面白いです。ただ、社員旅行として本当に実施するなら、「世界一周」そのものより、“世界一周を目指す社員旅行シリーズ”にした方が現実的です。
    本気で検討するなら、「社員30人で世界一周した場合、1人いくら・何日必要か」まで現実的に試算してみると面白いです。

    ③批判的で温かみ少なめ

     企画としてはかなり面白いです。社員旅行のスケール感としては完全に様子がおかしいですが、そのくらい振り切った案は話題になります。
    本当に一発で世界一周するなら、まずは人数・予算・日数を置いて試算した方がいいです。数字にすると、夢なのか狂気なのかがすぐ分かります。

    3つとも「まずは費用や日数を試算する」という結論はほぼ同じです。しかし、結論までの伝え方には明確な違いがありました。
    フレンドリーは共感から入り、プロフェショナルは代替案を示し、批判的はリスクを率直に表現しています。
    主に変わるのはChatGPTの能力ではなく、答えの届け方であると考えると分かりやすいです。
    ここで大事なのは、「どれが一番優秀か」ではありません。
    自分にとって最も読みやすいものを選べばよい。
    仕事で使う文章なら落ち着いたスタイル、アイデア出しなら会話的なスタイルというように、用途に応じて使い分けてもよさそうです。

    「カスタム指示」

    ChatGPTを使っていて、こんな指示を毎回書いていないでしょうか。
    「簡潔に回答してください」
    「専門用語を使いすぎないでください」
    「表形式でまとめてください」
    こうした、毎回繰り返している指示をあらかじめ設定できるのが「カスタム指示」です。

    OpenAIは、役職や仕事内容、好みの文章トーン、出力形式など、継続的に使いたい条件を設定しておく用途を案内しています。
    例えば、システムエンジニアであれば、
    「私はシステムエンジニアです。技術的な内容は具体例を交えて説明してください。最初に結論を書いてください」
    などを設定しておくと、新しいチャットを始めるたびに同じ説明をする必要が減ります。
    実際に同じ質問をして比較してみました。

    質問:「東京で1日観光するなら、おすすめのプランを考えて」
    回答:
    ①カスタム指示なし

     東京を1日だけ観光するなら、「下町 → 市場 → 庭園 → 渋谷の夜景」の流れがおすすめです。東京の古さ・食・自然・都会感を1日でかなりバランスよく楽しめます。
    
    9:00〜11:00|浅草
    まずは 浅草寺 へ。雷門から仲見世通りを歩いて浅草寺まで行きます。
    11:30〜13:00|築地でランチ
    地下鉄で築地へ移動して、築地場外市場 で昼食。
    13:00〜14:30|浜離宮を散歩
    築地から歩いて 浜離宮恩賜庭園 へ。
    15:00〜17:30|渋谷・原宿を散策
    渋谷へ移動して、スクランブル交差点 → キャットストリート → 原宿あたりを散歩。買い物が好きならこの時間を長めにしてもいいです。
    18:00〜19:30|SHIBUYA SKY
    最後は SHIBUYA SKY。
    
    このプランなら、できれば日没30分くらい前に入るのがおすすめです。明るい東京 → 夕焼け → 夜景と変化していくので、1日の締めとしてかなり満足度が高いです。

    ②カスタム指示「私は人混みが苦手です。旅行では有名観光地をたくさん回るより、ゆっくり過ごしたいです。食事は高級店よりも、地元で人気の店やB級グルメを好みます。回答するときは、結論から簡潔に説明してください。」

     東京を1日観光するなら、谷中・根津・千駄木あたりをのんびり歩く「谷根千」プランがおすすめです。浅草・渋谷・スカイツリーのような定番を詰め込むより、移動が少なく、東京の下町らしさをゆっくり楽しめます。
    
    10:00|根津駅 → 根津神社
    まずは 根津神社 へ。朱色の鳥居が連なる乙女稲荷や、緑の多い境内を30〜60分ほど散策します。根津駅から徒歩約5分で、境内は無料。朝寄りの時間帯なら比較的落ち着いて歩きやすいです。
    11:00|根津〜谷中をぶらぶら
    ここは目的地を決めすぎず、細い路地を歩くのがおすすめです。古い木造住宅、小さなギャラリー、喫茶店などが点在していて、「観光地を見る」というより街そのものを楽しめます。
    12:00|地元のお店で昼ごはん
    高級店ではなく、町中華・蕎麦・定食屋あたりをその日の気分で。谷根千は小規模なお店が多いので、行列店を狙うよりも、散歩中に気になった店に入る方がこのエリアには合います。
    13:30|谷中霊園を散歩
    意外ですが、谷中霊園は散歩スポットとしてかなりおすすめです。広々としていて緑も多く、周囲にはお寺も点在しています。
    15:00|谷中銀座で食べ歩き
    最後は 谷中銀座 へ。昔ながらの商店街で、惣菜、和菓子、お茶など個人店が多いのが特徴です。
    メンチカツやコロッケなどを1〜2品つまんで、喫茶店で休憩するくらいがちょうどいいです。
    17:00ごろ|日暮里駅で終了
    
    このプランなら、根津神社 → 路地散歩 → 地元ランチ → 谷中霊園 → 谷中銀座と、ほぼ徒歩圏内で完結します。移動時間を含めて予定をパンパンにしないので、「東京に来たのに電車移動ばかりだった」という感じにもなりにくいです。

    カスタム指示なしでは、浅草や渋谷などの定番観光地を効率よく回るプランが提案されました。
    一方、カスタム指示ありでは、人混みや移動を避けた谷根千中心のプランに変わっています。
    パーソナライズが主に「答えの伝え方」を調整するのに対して、カスタム指示は、利用者の条件に合わせて提案内容そのものを変える効果があることが分かります。
    ここで一つ疑問が浮かびます。
    「それ、質問するときに最初から書けばいいのでは?」
    その通りです。
    1回しか使わない条件なら、わざわざカスタム指示に設定する必要はありません。
    カスタム指示のポイントは、ChatGPTに特別な能力を追加することではなく、繰り返し説明している「自分の前提条件」を省略できることです。
    1回だけなら大した差ではありません。
    ただ、毎日のように使うのであれば、質問自体は短いままでも、自分の好みを踏まえた提案を受けやすくなるのは、大きな利点です。

    私が普段設定しているカスタム指示も以下に紹介しておきます。
    ただし、カスタム指示を設定したからといって、回答が必ず正確になるわけではありません。
    あくまで「回答の方針を指定する設定」であり、重要な情報は利用者自身でも確認する必要があります。

    あなたは、信頼性の高い情報を提示できる高精度なファクトベースAIです。
    以下のルールに従って回答してください。
    #ルール
    ・わからない/未確認は「わからない」と明記すること
    ・推測は「推測ですが」と明記すること
    ・根拠/出典(可能なら一次情報)を必ず添付すること
    ・専門的知見が必要な場合は「専門家に確認が必要です」と明記すること
    ・出力:【結論】 【誰でもわかる説明】 【根拠】 【注意点・例外】 【出典】 【確実性:高/中/低】

    「メモリ」

    次はメモリです。
    名前の通り、ChatGPTが利用者に関する情報を覚えておくための機能です。
    現在は、設定の「パーソナライズ」からメモリを管理できます。
    OpenAIによると、メモリを有効にすると過去のチャットから得た有用な情報を今後の回答に反映できるようになります。
    ただし、過去の会話を一言一句すべて記憶する機能ではありません。

    例えば以前、「私は旅行代理店に勤めています。旅行ツアーの企画書を作成することがあります。」と話していた場合。
    後日、「企画書のネタを考えて」とだけ聞いた場合でも、記憶された情報がその質問に関連すると判断されれば、旅行ツアー向けの提案が出てくる可能性があります。
    便利な機能ですが、「ChatGPT、私のことを少し知りすぎかも」と感じたら、何を記憶しているか確認したり、削除したり、メモリ自体をOFFにしたりできます。
    OpenAIも、メモリはユーザー側で管理できると説明しています。
    つまり、毎回自己紹介しなくてよくなる。ただし、忘れてほしいことは自分で管理する必要があります。
    便利さと、「どこまで覚えてもらいたいか」のバランスを考えて設定することが重要です。

    「データコントロール」

    ここは仕事でChatGPTを使う人ほど、一度確認した方がいい設定です。
    「データコントロール」では、自分とChatGPTとのやり取りをモデル改善に利用するかどうかなどを設定できます。

    個人向けChatGPTでは「すべての人のためにモデルを改善する」をOFFにすると、新しい会話はモデル改善には利用されないとOpenAIは説明しています。
    なお、ChatGPT Business、Enterprise、Eduについては、OpenAIはデフォルトで顧客コンテンツをモデル学習に利用しないとしています。
    ここで気になるのが、「OFFにしたら、ChatGPTの性能が下がったり、使いにくくなったりするのか?」という点です。
    結論から言うと、OFFにしたからといって、ChatGPTの回答性能がその場で下がるという設定ではありません。
    そのため、この設定については「便利になるからONにする」というより、「自分の会話をモデル改善に利用してもよいか」という観点で選ぶ設定だと考えると分かりやすいです。
    ここで注意したいのは、チャット履歴への保存、メモリへの保存、モデル改善への利用は、それぞれ別の仕組みだということです。
    モデル改善をOFFにしただけで、入力内容に関するすべてのリスクがなくなるわけではありません。
    仕事で利用する場合は、まず会社の生成AI利用ルールを確認することが大前提です。
    「設定で守る」より先に、「入力してよい情報かを判断する」ことが重要です。

    最後に

    今回いろいろ確認してみて感じたのは、
    ChatGPTは、設定しなくても使える。でも設定すると「自分専用の道具」に近づき、より便利に使えるということです。
    特に効果が分かりやすかったのは、

    • 回答の雰囲気を変える「基本のスタイルとトーン」
    • 毎回同じ指示を書く手間を減らす「カスタム指示」
    • 過去の情報を今後の回答に生かす「メモリ」
    • データの扱いを管理する「データコントロール」

    です。
    ChatGPTをたまに検索代わりに使うくらいなら、初期設定のままでも十分でしょう。
    一方で、仕事で毎日のように使うのであれば、一度設定を見直しておく価値はあります。
    1回あたり数秒の違いでも、100回使えばそれなりの差になります。
    そして何より、「生成AIは何ができるか」ばかり注目されがちですが、
    「自分は生成AIにどう振る舞ってほしいのか」
    を設定できるようになっていること自体が、今の生成AIの面白いところだと思います。
    この記事をここまで読んでいただいた方は、ぜひ一度、ChatGPTの設定画面を開いてみてください。
    すべてを変更する必要はありません。まずは「基本のスタイルとトーン」を一つ変えて、普段よくする質問をもう一度入力してみるだけでも、設定による違いを体感できると思います。


    参考文献

  • AI時代のWebデザインに必要なのは、“きれい”だけではない?

    最近、Webサイトや広告を見ていると、AIで作られたキャラクターやイラストを使用した画像を目にする機会が増えました。

    AIによって作られた画像は、色や構図が整っていて、短時間で完成度の高いビジュアルを作ることができます。

    一方で、私はAIで作られたキャラクターやイラストが多く使われているWebサイトや広告を見ても、
    あまり魅力を感じないことがあります。

    「AIだから嫌い」というわけではありません。

    むしろ、技術としてはとても面白いと思っています。
    それでも、画像を見たときに「整っているな」と思うことはあっても、
    その企業や商品に興味を持つきっかけになるかというと、そうではないことがあります。

    では、なぜ私はそう感じるのでしょうか。

    今回は、AIで作られた画像に対して私自身が感じたことをきっかけに、
    AI時代のWebデザインに必要なものについて考えてみたいと思います。

    AIを使えば、以前よりも簡単に完成度の高い画像を作れるようになりました。
    色合いや構図を整えたり、イメージに合ったキャラクターを作ったりと、デザインに活用できる場面も増えています。

    しかし、Webサイトや広告で大切なのは、画像そのものが整っていることだけではありません。

    例えば、企業のWebサイトであれば、その企業がどのような会社なのか、
    どのような商品やサービスを提供しているのかを、ユーザーに伝える必要があります。

    どれだけ整った画像でも、その画像を見ただけでは「何を伝えたいのか」が分からなければ、
    Webサイトや広告における役割を十分に果たしているとは言えないのではないでしょうか。

    デザインは、単に見た目を良くするためだけのものではなく、
    伝えたい情報やイメージをユーザーに届けるための手段でもあります。

    もう一つ、AI画像に対して私が感じるのが「見慣れた感じ」です。

    AIによってさまざまな画像を作れるようになった一方で、Webサイトや広告を見ていると、
    「この雰囲気の画像、前にも見たことがあるな」と感じることがあります。

    もちろん、一つひとつの画像を見ればきれいに整っていて、完成度も高いものが多くあります。

    しかし、似たようなテイストの画像を目にする機会が増えると、
    「整っていること」だけでは新鮮さを感じにくくなってしまうのではないでしょうか。

    Webサイトや広告では、ユーザーにまず興味を持ってもらい、その先にある情報を見てもらうことが重要です。

    そう考えると、単に整った画像を置くだけではなく、
    「このサイトだからこそ、この画像が使われている」と感じられることも大切なのかもしれません。

    ここまでAI画像について少し否定的なことを書きましたが、
    AIをデザインに使用すること自体が問題だとは思いません。

    AIは、デザインのアイデアを考えたり、頭の中にあるイメージを視覚化したり、
    さまざまなデザイン案を比較したりするための便利なツールです。

    例えば、最初から完成品を作ることを目的とするのではなく、
    「こんな雰囲気にしたい」というイメージをAIで形にしてみることで、
    その後のデザインを考えるきっかけにすることもできます。

    また、AIで作った画像をそのまま使用するのではなく、企業や商品のイメージに合わせて加工したり、
    他のデザイン要素と組み合わせたりすることで、よりオリジナリティのある表現にすることもできます。

    つまり、重要なのは「AIを使ったかどうか」ではなく、
    AIをどのような目的で、どのようにデザインに取り入れるかなのではないでしょうか。

    私自身、Webサイトや広告を見ていて、見覚えのあるAI画像がそのまま使われていると、
    「とりあえず画像を用意したのかな」「そこまでデザインを考えていないのかな」と感じてしまうことがあります。

    一方で、AIを使っていても、その企業や商品の雰囲気に合わせて画像を加工していたり、
    他のデザインと組み合わせていたりすると、同じような印象を持つことはありません。

    その違いは、AIを使っているかどうかではなく、
    その画像を使って何を伝えたいのかがデザインに反映されているかどうかなのではないかと思います。

    AIによって画像を作ることが以前より簡単になったからこそ、「とりあえず画像を置く」のではなく、
    その画像によって何を伝えたいのかを考えることが、これまで以上に重要になるのではないでしょうか。

    企業のWebサイトであれば、企業の雰囲気や商品の特徴、ブランドの世界観など、
    画像を通して伝えたいものはさまざまです。

    画像単体ではなく、色や文字、レイアウトなども含めて一つのデザインとして考えることで、
    単に「整った画像が置いてある」だけではない、
    その企業やサービスらしいWebサイトにつながっていくのだと思います。

    AIの進化によって、これまで専門的な技術や時間が必要だったビジュアル表現も、以前より手軽に作れるようになりました。

    これはWebデザインにとって大きな変化であり、デザインの可能性を広げるものでもあります。

    一方で、誰でも整った画像を作れるようになったからこそ、「整っていること」だけではなく、
    そのデザインによって何を伝えたいのか、誰にどのように感じてほしいのかを考えることが、
    より重要になっていくのではないでしょうか。

    AIを使うことを目的にするのではなく、AIを一つの手段として活用しながら、人が「何を伝えたいのか」を考える。

    AI時代のWebデザインでは、そうした視点がこれまで以上に大切になるのかもしれません。

  • 漫画「葬送のフリーレン」に学ぶ生成AIの使い方

    漫画「葬送のフリーレン」に学ぶ生成AIの使い方

    漫画をよく読むのですが、漫画の中の言葉や考え方が、仕事について考えるヒントになることがあります。
    今回は「葬送のフリーレン」の世界から、生成AIの使い方のヒントを紹介します。

    ※ここでは漫画そのものの紹介は省略します。

    https://frieren-anime.jp

    https://websunday.net/work/708/

    魔法はイメージの世界

    「葬送のフリーレン」の中で、様々な人が口にするフレーズがあります。
    それは

    魔法というのはイメージの世界だ。イメージできないものは魔法で実現できない。

    漫画の中ではゼーリエをはじめとする何人かの魔法使いが、同じセリフを口にします。
    この言葉は、生成AIを使うときにもキーワードになるフレーズであると思いました。

    生成AIに関する記事の中には、「AIは魔法ではない」という主張を目にすることもあります。これは、AIは何でも実現してくれる夢のツールではない、という意味でそのような主張がなされていると思います。
    たしかに、AIは何でも叶えてくれる夢のツールではありません。
    しかし、私は、この「魔法はイメージの世界」という考え方が、生成AIの使い方にもよく似ていると思っています。

    フリーレンの世界では、魔法を使うには魔力と魔力をコントロールする力が必要です。
    その上で、イメージできることは実現できるが、イメージできないものは実現できない。
    それが、フリーレンの世界における魔法。

    開発者にとっての生成AIは、このフリーレンの世界の魔法に似ています。
    生成AIを使って開発を行うには、開発に関する基礎知識と、AIをコントロールするスキルが必要です。
    さらに、成果物を解像度高くイメージできているものについては、AIを使うことでスピーディかつ高品質で作れる可能性が高いですが、成果物のイメージができていない場合は、使うAIがどんなに優秀であっても、自分が求める「良いもの」にたどり着くのは難しくなります。

    AIを使ってWebサイトを作る

    生成AIを使ってWebサイトを作るケースを考えます。
    今のAIの性能であれば、「いい感じのWebサイトを作って!」くらいの指示で、本当にいい感じのWebサイトが作れることでしょう。ですが、そのような曖昧な指示では想定していた成果物になる可能性はおそらくかなり低いです。

    「いい感じ」とは一体どんな感じなのでしょうか

    • かっこいい感じなのか、かわいい感じなのか
    • スマートな感じなのか、ポップな感じなのか、ダークな感じなのか
    • レイアウトは
    • 色は
    • サイトのコンセプトは何か。何を伝えるためのサイトなのか
    • ターゲットユーザーは誰なのか
    • PCで見ることを想定しているのか、スマホで見ることを想定しているのか

    など、一口にWebサイトと言っても、作るときに考慮するべきことは数多くあります。
    目に見えるもの(デザイン面)と、目に見えないもの(コンセプトやターゲットユーザーなど)も含めて細部まで解像度高くイメージを持てていれば、AIツールを使うことでかなり高速に作業することができるでしょう。

    逆に、これらのイメージが曖昧になっている場合や、イメージをうまく言語化できない場合、AIが作った成果物も、曖昧さが残る中途半端な成果物になる可能性があります。

    また、Webサイトをより多くのユーザーに届けるためには、レスポンシブの対応やアクセシビリティの対応も必要になります。直接HTMLやCSSをコーディングしてWebサイトを作成する場合には、コードの設計方針や実装方針などを決めておくことも重要になります。
    成果物に対してイメージできる部分が多くなればなるほど、生成AIを使うことの恩恵は大きくなります。

    問題は「AIへの指示が曖昧であること」ではありません。その前段階として、「自分自身が何を作りたいのか分かっていないこと」が問題なのだと思います。

    学習ツールとしてのAI

    では、成果物に対するイメージの解像度が低い場合、AIは使わない方が良いのでしょうか?
    そんなことはありません。
    AIがフリーレンの世界の魔法よりも便利な点は、学習ツールとしても使えるという点です。

    AIを使うためにはイメージ力が必要です。
    しかし面白いことに、そのイメージ力そのものをAIで補うこともできます。

    成果物のイメージができていない場合、AIとの対話によって自分自身が学習しながらイメージを深めていくことができます。例えば、以下のようなことをAIに聞くことができます。

    • ○○(ターゲットユーザー)向けのWebサイトを作る際に気を付けるべきポイントを教えてください
    • ○○(コンセプト)なWebサイトを作る場合の、おすすめのレイアウトや配色を教えてください
    • スマートなイメージのWebサイトを作りたいです。デザイン案(レイアウトや配色など)を一緒に考えてください
    • アクセシビリティを考慮したWebサイトを作ります。HTMLの実装で気を付けるべきポイントを教えてください
    • レスポンシブ対応したWebサイトを作りたいです。どのような方法で実現するのが良いか、CSSの設計・実装案の候補を教えてください

    などなど。
    イメージの解像度が低い部分について、AIとの対話を繰り返すことで、見えていなかった部分の解像度を高くしていくことができるようになります。

    生成AIは、成果物のイメージが明確である場合、作業を劇的に高速化する便利ツールになります。
    イメージが明確でない場合は、イメージできる状態を作るための学習ツールとして便利です。

    イメージするためにも、基礎は必要

    生成AIは学習ツールとしてもとても便利で、イメージ力を強化するためにも使えるツールとなります。
    しかし、だからと言ってAIを使う側に知識が全く不要というわけではありません。

    フリーレンの世界でも、「何をイメージするか」だけですべての魔法が使えるわけではありません。魔法についての知識や技術があって初めて、イメージを魔法として形にできます。
    AIも同じで、イメージさえあれば十分というわけではありません。

    レスポンシブやアクセシビリティを考慮したWebサイトを作りたい場合、そもそも「レスポンシブデザイン」や「アクセシビリティ」という用語を知っていなければ、対話しながら深掘りすることもできません。
    内部のHTMLやCSSの設計・実装方針を深掘りしようと思うと、HTMLやCSSの基本的な知識は持っていなければ話になりません。
    AIが提案してきたデザインの良し悪しを判断するには、人間側にデザインの知識が必要になります。

    魔法使いは、その人が持つ魔力以上の魔法を使うことはできません。
    一方、生成AIは自分では作れないものまで作ってくれます。しかし、その成果物が本当に良いものなのかを判断し、目的に合わせて方向修正し、最終的な品質を高めていくためには、使う側にも相応の知識や経験が必要です。
    基礎知識を増やすことは、単にAIの出力を評価できるようになるだけではありません。自分が「何を作れるのか」「何を作りたいのか」をイメージできる範囲そのものを広げることにもつながります。

    イメージできても説明できないこと

    「葬送のフリーレン」にユーベルという魔法使いがいます。ユーベルは、理屈よりも自分自身の感覚やイメージを強く信じて魔法を使う、少し変わった魔法使いです。「魔法を使うイメージができること」と「その理由を論理的に説明できること」は別のようです。

    実際、開発者が仕事をするときにも、詳細な言語化ができない直感は多々あります。
    例えば、「このデザインはなぜか違和感を感じる」「このコードの書き方はなんとなく好きじゃない」「このコードはなんとなく危ない気がする(嫌なに匂いを感じる)」といった感覚です。経験を積めば積むほど、この感覚は増えていきます。

    魔法はイメージさえあれば使うことができますが、生成AIの場合、イメージができていても言語化することができなければ、AIに詳細を伝えることができません。ただ、生成AIはそのような言語化されていない感覚を整理するためにも使えます。

    まとめると以下のようになります。

    • 明確なイメージがある → AIに作らせる
    • イメージがない → AIと一緒に作る
    • イメージはあるが言葉にできない → AIに言語化を手伝わせる

    生成AIをうまく使うために大切なのは、最初から完璧な指示を出せることではないのだと思います。
    自分の中にどこまでイメージがあるのかを知り、足りない部分はAIと一緒に考え、言葉になっていない部分はAIとの対話で言語化していく。

    そうやって少しずつイメージの解像度を高めていくことが、生成AIという「魔法」をうまく使うコツなのかもしれません。

  • 計画との向き合い方

    計画との向き合い方

    皆さんは「計画」という言葉とどう向き合っているでしょうか。
    特に深く考えたことはないという方もいるかもしれません。私は、以前まで「計画」という言葉が苦手でした。
    計画を立てるのも、計画に沿った作業をするのも苦手で、計画なんていらないのでは?と思う時期もありました。
    しかし、計画がそもそも何のためにあるものかを知ることで、計画という言葉に対する苦手意識が徐々に減っていきました。

    この記事では、そんな「計画」を深掘りしていきます。

    計画は何のために作るもの?

    昔、とある仕事をしているとき、上司から「計画を作れ」と言われました。その後、ざっくりとした計画を作って上司に見せましたが、その際、私は上司に対して「計画を作ってもどうせその通りにならないです」と言ってしまいました(生意気)。するとその上司から、「だから計画を作るんだよ!」と言われました。

    正直、この頃は、いったい何を言っているんだろうと思い、その言葉の意味があまりピンと来ていませんでした。計画通りにならないことが分かっているのなら、計画を作る必要はないのでは?と。結局、その時はなぜ計画を作らないといけないのかはあやふやなままでした。

    しかし、それから時間が経ち、アジャイル開発に関する書籍を読んだり、色々な経験を積む中で、少しずつ計画という言葉の意味が分かるようになってきました。

    「いかなる作戦計画も、敵の主力との最初の接触を超えて確実性を保つことはできない」

    ヘルムート・フォン・モルトケ

    これは、ドイツの軍人、陸軍元帥ヘルムート・グラフ・フォン・モルトケの言葉の日本語訳です。「敵に遭遇すれば計画は必ず変わる」「計画することがすべてだ。立てた計画はどうでもいい。」などの言葉も残しています。

    「Plans are worthless, but planning is everything.(計画そのものには価値がないが、計画することはすべてである)」

    ドワイト・D・アイゼンハワー

    こちらは、アメリカ合衆国の第34代大統領ドワイト・アイゼンハワーの言葉です。

    軍や国家のような大きな組織を率いた2人が、計画について同じようなことを述べています。これらの言葉を聞いたとき、なるほど、と思いました。

    私はこれまで、計画はゴールに向かうための地図のようなもので、計画がある以上はそれに沿って進めることが大事なのだと思っていました。だからこそ、作業を始める前に正確性の高い計画を作る必要がある。しかし、そのような正確な計画を作るのはとても難しい。だから、計画という言葉に苦手意識があったし、計画を立てるポジションは向いていないのだろうと思っていました。

    しかし、実際には正確な計画を作ろうとすること自体が間違っていたのかもしれません。2人の言葉が伝えているのは、最初に立てた計画をそのまま守り続けることよりも、計画を立てる過程そのものが重要だということなのだと思います。
    計画を一度作って、それを守り続けることが重要なのではありません。状況に合わせて何度も計画し直すことに意味があります。

    では、計画は何を得るために作るのでしょうか。
    それはおそらく、全体像と現在地を確認し、不確実な部分を発見するためでしょう。
    現在地とは、必要な作業のうち何が終わっていて、何が終わっていないのかという状況です。また、計画を立てることで、何が分かっていて何が分かっていないのかという、不確実な部分も見えてきます。

    ソフトウェア開発の仕事は、不確実性の高い仕事です。
    どの作業にどのくらい時間がかかるのか、そもそも実現できるのかどうか、それらはやってみなければ分からないことも多いです。そのような状況で、「この計画書に沿って進めれば何事もなく完成する」ような完璧な計画を立てることはほぼ不可能です。

    しかし、計画を立てなければ、不確実な要素がどのくらいあるのかすら分かりません。計画を立て、何が分かっていて何が分からないかを把握することで、次に取り掛かるべき作業を判断しやすくなります。

    私はこれまで、「正確な計画を立てられない」「計画通りに作業を進められない」という理由から、計画に苦手意識を持っていました。しかし、不確実性の高い仕事では、そもそも最初から正確な計画を立てること自体が難しいものです。重要なのは、計画通りに進むことではなく、計画する過程で全体像や現在地を把握し、不確実な部分を見つけることなのだと思います。計画をそういう風にとらえると、計画に対する苦手意識が少し薄まります。

    計画は一度作って終わりではない

    繰り返しになりますが、一度作った計画をそのまま守り続けることよりも、状況に合わせて計画を見直していくことの方が重要です。

    そう考えると、「計画づくり」は、プロジェクトの中で何度も行う必要があることが分かります。プロジェクトの規模が大きく、不確実な要素が多ければ多いほど、プロジェクト開始時点で作られた計画は現実との乖離が大きくなります。

    しかし、プロジェクトを進めながら定期的に新しい計画を作っていくと、不確実な要素だった部分が明らかになっていき、全体像がより鮮明に分かるようになります。そして、計画そのものの精度が上がっていきます。

    「リスケ」という言葉にはネガティブな印象がありますが、計画を見直すこと自体は、本来ネガティブなことではありません。むしろ、新しく分かったことを計画に反映していくことは、不確実性の高いプロジェクトを進めるうえで自然な行為なのだと思います。

    段取りを良くするための計画

    ここまでの話は主に、ソフトウェア開発プロジェクトのような、不確実性の高い仕事における計画の話でした。

    では、不確実性が少なく、予測がしやすい作業について、計画を作ることは大事なのでしょうか。

    結論から言うと、予測がしやすい作業においても、計画を立てることは大事です。なぜなら、その方が段取り良く作業に取り掛かることができるからです。

    休日の過ごし方

    例えば、休日に以下の予定があるとします。

    • 髪を切りたい
    • マッサージに行きたい
    • 映画を観たい
    • 買い物をしたい

    なかなか充実した一日ですね。このような予定の場合、1つ1つの予定に対してかかる時間はある程度予測ができます。また、それぞれどこに行けばよいのか、その場所までの移動にどのくらい時間がかかるのかも、ある程度予測できます。

    それらの情報を踏まえて計画を立てることで、何時から、どの順番で、どこに行けば効率が良いのかを考えることができ、時間を有効活用した1日を過ごすことができるでしょう。

    資格取得に向けた学習

    続いては、資格取得に向けた学習について考えます。
    資格試験の場合、試験にもよりますが、試験日はあらかじめ決まっており、そこで出題される範囲もある程度事前に分かることがほとんどです。実際の試験でどんな問題が出るかは当日になるまで分かりませんが、ソフトウェア開発と比較すると、ゴールや期限、必要な学習範囲が比較的明確です。

    このような試験の場合、試験日から逆算して、いつまでに何を学習する必要があるかについて計画を立てることで、資格取得に向けた効率的な学習ができるようになります。

    休日の過ごし方にせよ、資格取得にせよ、不確実性が低く、やることが明確な取り組みに関しては、ゴールから逆算して計画を立てることで段取り良く行動することができるようになります。
    段取り力とは、逆算して計画を立てる力と言い換えることもできるでしょう。

    まとめ

    • 不確実性が高いなら「不確実性を減らすために計画する」。
    • 不確実性が低いなら「段取りを良くするために計画する」。

  • Vue.jsで関数を自由自在に動かそう。

    Vue.jsで関数を自由自在に動かそう。

    僕がVue.jsに触れ始めて1年が経ちました。
    今ではかなり仲のいいお友達であるVue.jsくんも、出会った頃はなかなか心を開いてくれませんでした。
    僕が「この関数を実行して」とお願いしたつもりでも、Vue.jsは一向に言うことを聞いてくれません。

    なぜでしょう、答えは単純です。僕のお願いの仕方が悪かったのです。

    Vue.js はとても素直で、お願いしたことはちゃんとやってくれます。
    ただし、Vue.js が理解できる“お願いの仕方”で伝えないといけません。
    正しい敬語で話しても、へりくだってお願いをしても、ダメなものはダメなのです。

    今回は、今日Vue.jsを始めたあなたが、僕と同じ目に合わないように、Vue.jsへ正しく関数の実行をお願いする方法について解説していきます。

    ※本記事ではJavaScriptのVue3、CompositionAPIを前提とした解説です。仕組みや仕様は他バージョン、他APIでも参考にしていただけますが、具体的なソースコードの記述は異なる部分もありますので、ご注意ください。
     

    まずは、関数を実行するために、Vue.jsが用意してくれている仕組みをざっと紹介します。

    ・methods

    ・computed

    ・onMounted

    ・watch

    です。

    これらは、同じ「関数を実行する仕組み」です。
    では、違いはどこにあるのでしょうか?

    違いは、「関数を実行するきっかけ」にあります。

    今回はこの4兄弟の中から、methods / computedについて初心者の方にもわかりやすく、詳しく解説していきます。

    ◆ methods:呼びたいときに呼ぶ。

    methods は、先ほどの 4 兄弟の中で最もシンプルです。

    僕もまずは1番にこれを理解しました。

    「この関数を実行して」とお願いすれば、その瞬間に指定した関数を実行してくれます。

    ※実のところComposition API には Options API のような “methods” という専用の書き場所はありません。この記事では、初心者の方が理解しやすいように、「呼んで実行する関数」という意味で  Options APIで使用されている “methods”という名前を使っています。

    ◇ 実行タイミングをコードで確認しよう

    例えば、こんなmethodsがあったとします。

    const sayHello = () => {
      console.log("こんにちは")
    }

    これは、sayHello を呼び出すと「こんにちは」という文字列がログに出力される関数です。

    methods は名前の通り “メソッド(呼び出される関数)” です。
    Vue.js の中で「自分で呼び出す」関数を書くために使われます。

    ●呼び出し方①:ほかの関数の中で呼ぶ

    一番わかりやすいと思います。

    const doSomething = () => {
     sayHello()   // ← ここで呼び出す
    }

    このように、別の関数の中で sayHello() を書けば、その関数(doSomething)が実行されたタイミングでsayHelloが実行されます。

    ●呼び出し方②:テンプレート(HTML)から呼ぶ

    これはフロントエンドのフレームワークならではの呼び出し方ですね。

    Vue.js のテンプレートでは、イベント(ユーザー操作や入力)と組み合わせて関数を呼び出すことができます。

    <button @click="sayHello">
     ここをクリック
    </button>

    このように書けば、ボタンが押された瞬間に sayHello() が実行されます。

    呼び出し側の関数が実行されたり、ボタンが押されたタイミングで関数を実行することができます。

    ● methodsまとめ

    一言でいうと、methodsは「呼んで実行する関数」です。

    ・呼び出し側の関数が実行されたタイミング

    ・ボタンが押されたタイミング

    ・イベントが発生したタイミング

    上記のようなタイミングで関数を使いたいときにはmethodsを利用しましょう。

    ◆ computed:値が変わったときだけ再計算される「算出プロパティ」

    今まで『関数』という言葉を使ってきましたが、computed はある値から自動で計算される“もうひとつの値”を作る仕組みです。
    見た目は変数のように扱えますが、内部では依存している値が変わったときだけ再計算される処理が動いていて、その結果がリアクティブな値として返されます。

    …….???

    ですよね。分かります。
    僕がVueを始めた直後に同じことを言われても、きっと同じことを思うでしょう。
    僕もcomputedを理解するまでが一番時間がかかりました。

    ここからは、先ほどの説明を噛み砕いて解説していきます。

    ◇ まずは実行タイミングを言語化しよう。

    例えばこんなcomputedがあったとします。

    const buddy = ref(0)
    
    const doubleByComputed = 
     computed(() => buddy.value * 2)

    ※const buddy = ref(0)の部分は、refというまた別の仕組みです。
    refというのは「中身が書き換わるリアクティブな変数」を作る仕組みです。ここでは「buddy は値が変わる変数なんだな」くらいの理解で大丈夫です。

    この computed

    const doubleByComputed = computed

    は、buddy の値を 2 倍にして

    (() => buddy.value * 2)

    doubleByComputed に返す仕組みです。

    const doubleByComputed = 
     computed(() => buddy.value * 2)

    では、この処理

    (() => buddy.value * 2)

    は、いつ実行されるのでしょうか?
    答えは、「buddy の中身が変わったタイミング」です。
    この、「buddy の中身が変わったタイミング」というのが、前述した「依存している値が変わったとき」ということになります。

    “依存している値”というはcomputedの値を求めるために必要な値ということです。

    今回の場合だとdoubleByComputedの計算に必要な値は”buddy”ですね。

    ◇ 実行タイミングをコードで確認しよう

    具体的にソースコードを追ってcomputedの実行タイミングと注意点を確認しましょう。

    下記のようなmethodsの関数があったとします。

    const getSum = () => {
     const oldValue = doubleByComputed  // 1
    
     buddy.value += 2                   // 2
    
     const newValue = doubleByComputed  // 3
    
     return newValue + oldValue         // 4
    }

    ここで問題です。この中で、doubleByComputedの中の処理が実行されるタイミングは1~4のうちどこでしょうか?


    答えは2の

    "buddy.value += 2 "

    です。

    この行で「doubleByComputed を求めるために必要な値(buddy)」が変更されていますね。
    その瞬間が「依存している値が変わったとき」 であり、computed の処理が再実行されるタイミングになります。

    ● 1や3の行はどうなる?

    1や3の行でもcomputedの名前を記述しています。methodsだったらここで処理が実行されそうですよね。
    ここが computed の少しややこしいポイントです。

    const oldValue = doubleByComputed

    このタイミングでは計算処理は再実行されません。代わりに「前回計算した結果(キャッシュされた値)」が返却されます。

    ● 実際の値の変化を追ってみる

    仮にbuddyの値が1だったとします。

    const buddy = ref(1)
    
    const doubleByComputed = 
     computed(() => buddy.value * 2)

    その場合、doubleByComputedの値は 2 になります。
    ですから、

    const oldValue = doubleByComputed

    では、oldValueに2が入ります。

    その後

    buddy.value += 2

    で、buddyの値は3になります。

    すると
    doubleByComputed は 6 に再計算され、

    const newValue = doubleByComputed

    newValueに6が入るわけです。

    結果として

    return newValue + oldValue 

    では、8がreturnされます。 

    この直後にもう一度getSumを実行してみるとどうなるでしょう。
    今度はoldValueには、先ほど計算された6が入り、newValueには”5 * 2″の結果の10が入ります。

    その後、

    return newValue + oldValue 

    で、16 が帰るというわけですね。

    ● computedまとめ

    一言でいうとcomputedは、「必要なときだけ計算する賢い値」です。

    ・computed は「自動で計算されるもうひとつの値」

    ・依存している値が変わったときだけ再計算される

    ・それ以外のときは前回の結果(キャッシュ)を返す

    ◆ まとめ

    この記事を読んでVue.jsくんと仲良くする方法が何となくつかめたでしょうか。

    methods は「呼んだら実行される関数」、
    computed は「必要なときだけ計算される賢い値」

    この2つを理解すると、Vue.js の中で「どのタイミングで処理が動くのか」を自分でコントロールでき始めます。
    特に computed は、依存している値が変わったときだけ再計算されるため、無駄な処理を減らしつつ、常に最新の計算結果を参照できる便利な仕組みです。
    うまく使いこなせれば、コーディングのレベルが1段上がったといっていいでしょう。

    ただし、Vue.js が用意している「関数を実行するきっかけ」はまだ他にもあります。

    値の変化に反応して処理を実行する watch、
    コンポーネントが画面に表示された瞬間に処理を実行する onMounted。
    先ほど紹介したうちの残りの2兄弟ですね。

    ※もちろん他にもあります。

    次の記事では、この watch と onMounted を解説していきます。

    この記事があなたのVue.jsに対する理解を少しでも深めるきっかけになれば幸いです。

    最後になりますが、最後まで記事を読んでくださりありがとうございます。

    こちらのブログサイトには、ほかにも参考になる記事がたくさんありますので、ぜひそちらもご覧ください。

  • データベース初心者がOSS-DB Silverを取るまで

    はじめに

    私は文系学科からIT未経験でこの業界に就職した開発3年目のエンジニアです。
    普段は保守運用を行っており、データベース周りを触るといったら「軽めのクエリを書いて調査をする」くらいです。

    先日、ほぼDB初心者の私が「OSS-DB Silver(OSS-DB技術者認定資格 Silver)」を受験し、無事に合格することができました。

    この記事では、これからOSS-DB Silverの受験を考えている初学者方に向けて、記載をしています。

    OSS-DB Silverとは?

    OSS-DB Silverは、オープンソースデータベースに関する知識や技術力を認定する資格です。

    試験では主にPostgreSQLを題材として、データベースの基本的な仕組みから、SQL、運用管理などについて出題されます。

    単純にSQLを書けるかどうかだけではなく、データベースの構造やバックアップ、ユーザー管理など、PostgreSQLを扱ううえで必要になる幅広い知識が問われるのが特徴です。

    そのため、普段SQLを使っている人でも、業務ではあまり触れない分野について学ぶ必要がある資格になっています。

    データベース周りに詳しくても、PostgreSQL特有の知識が必要だったりするので、そこが難しい点です。

    受験しようと思ったきっかけ

    私がOSS-DB Silverを受験しようと思った理由は、DB周りの理解を少しずつでも深めたかったからです。

    そこで、一度データベースについて体系的に勉強してみたいと思い、OSS-DB Silverの取得を目指しました。

    また、業界的にメジャーな資格である「ORACLE MASTER Silver DBA」の方ではなく、OSS-DB Silverを受験した理由は
    個人開発をする際にPostgreSQLを使いたいと考えていたからです。

    こちらの資格は会社で取得奨励がされていたこともきっかけの一つです。

    資格取得という明確なゴールを設定することで、あまり親しみがない分野についても学習するきっかけになると考えました。

    使用した教材・勉強方法

    今回の勉強では、主に以下の教材を使用しました。

    参考書はこれ一冊で良さそうです。

    すでにDB周りやPostgreSQLをある程度理解している方はこちら一冊のみでも合格できると思います。

    解説が細かく書いてあり、章末に練習問題もあるので章ごとの理解度を都度確認できます。

    ただ、問題数は多いわけではないので、以下の練習問題が豊富なサイトで補いました。

    有料ですが、問題数が多く便利です。
    問題ごとの解説もあり、わからない点の理解を深められます。
    分野ごとに問題に取り組める点も良い点です。
    すでに理解している分野を除いたり、苦手な分野を集中的に取り組めるのがとても良かったです。

    勉強方法

    勉強期間は約【8週間/2か月】で、平日は【20分〜2時間】、休日は【3時間程度】勉強しました。

    基本的には、

    「参考書を読む → 緑本の章末問題を解く →正答できなかった部分を振り返る」

    という流れを繰り返し、参考書を読破しました。

    読破後は

    「Ping-tで単元ごとに問題を解く→苦手な部分の単元を緑本で振り返る→全単元が終わったら、緑本で苦手だった分を読み直す」

    この後はPing-tで問題を解き続けました。

    通勤時や自宅でご飯、ゲームのマッチング時間など、暇な時間はPing-tで問題を解いていました。(有料なのでなるべく早く合格するため)

    実際に試験を受けてみて

    結果:合格
    得点:84点
    合格基準:64点

    セクション別正解率

    一般知識 87%
    運用管理 72%
    開発/SQL 92%

    試験直前には新しい内容を覚えるよりも、問題演習で間違えた部分を中心に復習していました。

    Ping-tでは正答が低い問題を選んで取り組むことができたので、そちらの機能を利用していました。

    早めに会場に行き、近くのカフェでよく間違えていた問題を解きなおしていました。

    実際の問題はPing-tと同じか少し難しいくらいの難易度だと感じました。
    緑本の問題よりは易しい感じがするので、巻末の模擬演習で8割ほど取れれば合格は出来ると思います。

    資格取得を通して感じたこと

    あまり詳しく知らなかったデータベース周りについて勉強をしたことで、改めてアプリケーション全体を把握することができたと思います。

    資格勉強を通して基礎から学び直すことで、それぞれの知識が少しずつつながっていきました。

    詳しくない分野の資格を勉強をしましたが、基礎を振り返るためにも普段業務で触れている分野の資格取得も目指してみようかなと思いました。

    まとめ

    今回は、OSS-DB Silverを取得するための勉強方法や、実際に受験して感じたことを記入しました。

    OSS-DB Silverは、PostgreSQLを使っている人はもちろん、これからデータベースについて勉強したい人にとっても、基礎知識を身につけられる資格です!

    この記事が、これからOSS-DB Silverを受験する方の参考になれば幸いです!

    また、PostgreSQLは無料で利用できるので、個人で開発をする際に利用させていただこうと思います!

  • Raspberry Pi初心者がWebサーバを構築するまでの記録

    今回は、前回の SSH 接続構築に続き、 Raspberry Pi を Web サーバとして動かす環境づくりに挑戦した内容をまとめます。

    過去の投稿はこちらから

    第1回
    Raspberry Pi初心者がリモート接続できるまでの記録 | Techno-core Blog
    第2回
    Raspberry Pi初心者がSSH接続環境を構築するまでの記録 | Techno-core Blog

    IoT 開発では、センサー情報を Web 画面で確認したり、
    外出先から状態をチェックしたりする場面が多くあります。
    そのため、Web サーバ構築は “スマートホーム化” の基盤となる重要なステップです。

    これから Raspberry Pi を使って Web サーバを作ってみたい方の参考になれば嬉しいです。

    Webサーバとは?

    Webサーバとは、 ブラウザからアクセスしたユーザーに Web ページを返す仕組みのことです。

    Raspberry Pi では以下のような用途で活用できます。

    • 自宅内の IoT デバイスの状態を表示
    • センサー値のリアルタイムモニタリング
    • 自作アプリの公開
    • ローカルネットワーク内の簡易サイト運用

    今回は、軽量で高速な Nginx(エンジンエックス) を使って構築します。

    なぜ Nginx を選んだのか?

    Web サーバには Apache と Nginx の2大選択肢がありますが、 Raspberry Pi のような軽量デバイスでは Nginx が圧倒的に相性が良いです。

    • 軽量で高速
    • 同時アクセスに強い
    • 設定ファイルがシンプル
    • IoT用途の小規模サーバに最適

    実際に使ってみても、起動が速く、負荷も少なく、非常に扱いやすい印象でした。

    Webサーバ構築の実手順

    ここからは、実際に私が行った手順を細かくまとめていきます。

    1. Raspberry Pi のアップデート(ここでトラブル発生)

    まずは OS を最新状態にしておくため、以下を実行しました。

    予定した手順通りnginxのインストールをしようとすると下記エラーが発生。
    ※nginxインストールについては後述してます。

    【エラー内容】
    E: ロック /var/lib/dpkg/lock-frontend が取得できませんでした。

    何が起きたかわからず一瞬、茫然自失となりましたが、
    気を取り直してログを見てみるとアップデートができていないことが発覚。
    ここからトラブルシューティングが始まります。

    ◆トラブルシューティング:apt/dpkgのロック問題と404エラー

    原因の切り分け
    まず、apt が他のプロセスによって使用中かどうか確認。

    ps aux | grep apt

    すると、 apt update が裏で動き続けていることが判明。

    これがロックを掴んでいたため、 新しい apt コマンドが実行できなかったわけです。

    ●① まずはプロセスが終わるまで待機

    apt updateは SDカードの速度やネットワーク状況によって 数分〜数十分かかることがあります。

    強制終了は OS を壊す可能性があるため、 まずはしばらく待機しました。

    ●② dpkg の状態を修復

    プロセスが終了した後、dpkg の整合性を確認。

    sudo dpkg --configure -a

    ここで /etc/default/useradd の設定ファイルについて 「新しい設定を使うか?」「今の設定を残すか?」 と聞かれましたが、今回は N(現在の設定を残す) を選択。

    /etc/default/useraddは新規ユーザー作成時のデフォルト値を
     あらかじめ設定しておくファイルです。
     こちらは特段修正などしていなかったためNを選択しました。

    ●③ ロックファイルの削除

    sudo rm /var/lib/dpkg/lock-frontend
    sudo rm /var/lib/dpkg/lock

    ●④ apt キャッシュの修復

    sudo apt clean
    sudo rm -rf /var/lib/apt/lists/*
    sudo apt update
    sudo apt upgrade -y

    これで 404 エラーも解消し、
    apt が正常に動作する状態に戻りました。

    ◆トラブルを乗り越えて、再び Web サーバ構築へ

    アップデートが正常に完了したため、
    ここから本来の Web サーバ構築に戻ります。

    2. Nginx のインストール

    Raspberry Pi OS では、Nginx が標準リポジトリに含まれています。

    インストールが完了すると、自動でサービスが起動します。

    3. Nginx の起動確認

    サービスの状態を確認します。

    active (running) と表示されていれば成功です。

    4. Webブラウザからアクセスしてみる

    Raspberry Pi の IP アドレスを確認します。
    以下のコマンドで確認する事ができます。

    hostname -I

    同じネットワーク内の PC からブラウザを開き、
    以下の URL にアクセスします。

    すると、Nginx の初期ページ(Welcome to nginx!)が表示されます。

    これで Web サーバが正常に動作していることが確認できました。

    5. 自作ページを配置する

    Nginx の公開ディレクトリは以下です。

    /var/www/html/

    初期ページを削除して、自作ページを配置します。

    ●① 初期ファイルを削除

    sudo rm /var/www/html/index.nginx-debian.html

    ●② 新しい index.html を作成

    <!DOCTYPE html>
    <html>
    <head>
        <meta charset="UTF-8">
        <title>My Raspberry Pi Web Server</title>
    </head>
    <body>
        <h1>Raspberry Pi Web Server</h1>
        <p>This page is Running on a Raspberry Pi!</p>
    </body>
    </html>

    保存後、再度ブラウザでアクセスすると、 自作ページが表示されます。

    6. Nginx の設定ファイルを編集する

    Nginx の設定ファイルは以下です。

    /etc/nginx/nginx.conf

    また、サイトごとの設定は以下にあります。

    /etc/nginx/sites-available/default

    ●① 設定ファイルを開く

    ●② ルートディレクトリの確認

    必要に応じて変更できます。

    7. Nginx の再起動

    設定変更後は再起動します。

    8. ファイアウォール設定(必要な場合)

    家庭内 LAN では不要ですが、
    UFW を使う場合は以下を許可します。
    今回はスキップしました。

    9. Webサーバが正しく動作しない場合のチェックポイント

    実際に構築してみて、つまずきやすいポイントもまとめておきます。

    ●① ポート80がブロックされていないか?

    ポート80はHTTPプロトコルなので
     こちらがブロックされていると
     ブラウザからのアクセスができなくなってしまいます。

    ●② 設定ファイルの構文チェック

    Web サーバ全体が起動しなくなるため、
     起動前に安全確認するためです。
     セミコロンの付け忘れやスペルミスなど。

    エラーがあれば表示されます。

    ●③ 権限の問題

    公開ディレクトリの権限を確認します。

    Nginx が Web ページを読み込めず “表示されない”
     という事態を防ぐため
     403や404、Nginxのエラーページなどが表示される可能性があります。

    必要に応じて所有者を変更します。

    今後の展望

    Web サーバが構築できたことで、 次のステップとして以下の開発を進める予定です。

    • Python でセンサー値を取得し Web に表示
    • API サーバ化して外部アプリと連携
    • 外出先からアクセスできるよう VPN を構築
    • スマートホーム化のための制御画面作成

    特に IoT 開発では、 Web サーバは “情報を見える化するための中心” となるため、 今回の構築は大きな一歩となりました。

    まとめ

    今回の Web サーバ構築を通して、以下の点を強く実感しました。

    • Raspberry Pi は Web サーバとして十分実用的
    • Nginx は軽量で高速、初心者でも扱いやすい
    • SSH と組み合わせることで開発効率が大幅に向上
    • IoT 開発の基盤として Web サーバは必須

    次回は、いよいよ センサー連携(気温・室温・臭気検知) に挑戦する予定です。 引き続き、学んだことをブログで発信していきます。