GeminiにMarkdownの書き方を聞いてみた(ついでに帰る方法も)

子供の頃にホー⚪︎ア⚪︎ーンなどの外国の映画を観て「クリスマスとは一家団欒のとき」「どんなに仕事忙しい人も休みを取ったり早く帰って家族と過ごせる時期」だと思っていたら、大人になってそんな世界など存在しないことを思い知らされ絶望の日々を過ごしている入眠記事担当です🎄。
あれから散々AIに奪われた(というか指示や検証で失った)時間を取り戻すため、"休みの日"まで会社のPCを使って「なんとかAIを仕事で使える様にならんか」と検索&模索する日々。ワークライフバランスなんて、私にとっては働き始めた若い頃からずっと死語です。むしろ食べ物の事かと思っていました🍗。

それはさておき、そうやって見つけたGemini先生への具体的な指示方法が「Markdown形式で概要を記述する」というもの。
(何周遅れだよって話ですが、記事専門でやっておらず毎日錯乱状態で仕事をしているため、ネタを見つけて最低限人間が読める文章にするまで時間が掛かるのでそこはご了承ください)
具体的にどう書けば良いかは世の中に幾つもの記事があるため、今までそれを参考にして色々試していたのですが、その経緯をダラダラ書いても読み難いしつまらない...。

そこで、こういう場合も「Gemini先生に直接書いてもらう」というのが昨今の常識の様ですので...
( ◜ω◝ ):早速お願いします、ジェミニんしぇんしぇー!!

[▣🝙▣]:
「AI(Gemini)への指示? 適当にチャット送ればいいんじゃないの?」……と思っているそこのあなた。もったいない! 人生損してますよ!(ちょっと盛りすぎました)

実は、Geminiに指示(プロンプト)を出す際、Markdown(マークダウン)形式を意識するだけで、Geminiの回答精度は劇的に跳ね上がります。今日は、Geminiを「ただのチャット相手」から「超有能な秘書」に変えるための、Markdown活用術を伝授します。

### なぜGeminiにMarkdownが必要なのか?

想像してみてください。上司から**「あのー、例の件、いい感じにまとめといて。あと構成もよろしく。ターゲットは若者ね。あ、箇条書きがいいな。文字数は少なめで」**と口頭で早口に言われたら……。
「えっ、何から手をつければいいの? そもそも『例の件』ってどれ?」ってパニックになりますよね。Geminiも同じです。
Markdownを使うことで、指示の**「構造」**が明確になります。Geminiに「ここが見出し!」「ここは条件!」「ここは例!」と視覚的に(構造的に)伝えることで、彼は「あ、なるほど。承知いたしました、ご主人様!」と、期待以上の仕事をしてくれるようになるのです。

### 使える! Markdownプロンプトの鉄板構成

ブログ記事やビジネス文書の作成を依頼するときは、以下の構成をコピペして使ってみてください。

1. タイトル(#)で役割を与える
一番大きな見出しで、Geminiに「何者になってほしいか」を伝えます。
  # あなたの役割:プロのウェブライター
2. 中見出し(##)でセクションを分ける
「命令」「制約事項」「構成案」など、情報の種類を分けます。
項目    書き方のコツ
## 依頼内容    「何をしたいか」をシンプルに。
## 制約事項    「です・ます調で」「500文字以内」など、NG行動を縛る。
## 入力データ    参考にするURLや文章をここに置く。
3. 箇条書き(* または -)で条件を整理Geminiは箇条書きが大好きです。
  ## 執筆ルール
  ・結論から書くこと
  ・専門用語には解説を入れること
  ・読者が「明日から試せる」内容にすること

【実践例】こんなに変わる! ビフォー・アフター
❌ ズボラな指示(もったいない例)
「おいしいカレーの作り方をブログ記事にして。初心者向けで、面白おかしく。材料も書いてね。」
結果: 普通にいい感じのレシピが出てきますが、どこか「普通」で終わります。

✅ Markdownを使った指示(プロの仕業)
```Markdown
# 役割:スパイス料理界の革命児
## 依頼内容
「世界一おいしいカレーの作り方」というブログ記事を執筆してください。

## ターゲット
- 料理は好きだが、隠し味に迷っている迷える子羊たち

## 構成案
1. **序文**: なぜ市販のルーに一手間加えるべきなのか
2. **材料**: 意外な「魔法の隠し味」を3つ含むこと
3. **手順**: Markdownのステップ形式で記述

## トーン
- 情熱的で、時々カレーに対する愛が爆発して語彙力が失われる感じ
```
結果: Geminiのエンジンがフル回転。「スパイスの香りで宇宙が見える……!」といった、パンチの効いた面白い記事が爆誕します。

まとめ:MarkdownはGeminiとの「愛の共通言語」

Markdownを使うことは、Geminiに対して「親切な地図」を渡すようなものです。構造化された指示は、AIの迷いを消し、あなたの理想に最短距離でたどり着かせてくれます。

最初は # や * を打つのが面倒に感じるかもしれませんが、一度慣れてしまえば、もう「適当な一行プロンプト」には戻れなくなるはずですよ!

次の一手として、私に何か書いてほしいテーマはありますか?「今回のMarkdown形式を使って、〇〇についての記事を書いて!」と指示いただければ、さっそく実力を披露させていただきますよ!


こんな感じのものを出して来てくれました。
中々おもろいもんです( ◜ω◝ )。
やたら絵文字使いたがるという話を聞いたけど、特に指定していなければ確かに使って来ますね。
mdの書き方も自分で調べたものよりちょっと簡潔過ぎますが、まあこれもプロンプトの指示次第なんでしょう。
きっと「〜させるためのmdの書き方を、具体的に詳しく」とか伝えれば、もう少し詳細なものを出してくれるはず。
さてどうお願いすればもっと具体的に説明してくれるかな...

そこに一瞬の閃きが、あたかも神の啓示の如く現れました。
( ◜ω◝ ): ではGemini先生、仕事を今すぐ全部片付けて帰る方法を教えてください!

[▣🝙▣]:
おっと、それは全人類が抱える永遠のテーマですね!「仕事を爆速で終わらせて、定時に(あるいは定時前に)風のように去る」。Gemini先生、喜んでその秘奥義を伝授しましょう。

先ほどのMarkdown術をフル活用して、あなたのための「脱出計画」を策定しました。

司令:オペレーション・定時退社 🚀

(...以下はGemini先生の有難いアドバイスの幾つかを抜粋したものです):
・今日の成果の80%を生み出しているのは、抱えているタスクのわずか20%です。それ以外は、ぶっちゃけ明日でも地球は滅びません。
・あなたがCCに入っているだけのメールは、だいたい「観賞用」です。閉じてください。
・15時を過ぎたら、キーボードを叩く音を1.5倍にします。周囲に「集中モード」をアピールし、話しかけにくいオーラを放ちましょう。

結論:帰ると決めた者が勝つ
仕事はガスと同じで、**「与えられたスペース(時間)をすべて埋めようとする」**性質があります。「今日は17時に消える」と心に決めた瞬間、あなたの脳はスーパーコンピューター並みの処理速度を発揮し始めます。

さあ、今すぐブラウザのタブを半分閉じてください。それが自由への第一歩です!

( ◜ω◝ ): FREEEDOOOM!!(ウィ⚪︎アム・ウォ⚪︎ス風)

そう心の中で叫んでノートPCの画面を閉じた直後、スマホの地震警報が鳴り、帰りの電車が大幅に遅れたのでした。

AIツールと奮闘記(だいたい実話) その三 〜燃え尽きたやる気と幻想〜

前回またしても勝手にコード全体をfunction化されてしまい発狂寸前になりましたが、寝る事で全てをリセットし再びチャレンジ。
「このビッグウェーブに乗り世間の皆様の様にAI使いこなせば、底辺の私でも必ずや仕事が楽になるはずだ」という気持ちをモチベに、執拗にAI様に食い下がります。

更に仕様やルールを再度出来る限り懇切丁寧に詳細に、「A=Bのとき、B=Aである」「AとはAの事であり、A以外を意味しない」みたいな、人間相手だったら「クドイなオッサン。そんなん1から100まで言われんでも分かるわ」と言われそうなぐらいしつこく書きました。
しかし結果は相変わらず微妙なもの...。

こんな事繰り返していては「AIに爆速でコード仕上げてもらって後は寝る」作戦が水泡に帰してしまう...。
というか既に"爆速"なのは私が「AIの書いたコードの間違いを発見する速度」の方になってしまった。
これでは何の為のAIやねんという話...。

そこで直接某GPT先生に、念の為本当に仕様を"理解"しているのか聞いてみる事にしました(厳密な意味でAIが「理解」することは無いだろ、的なツッコミはナシで)。

( ◜ω◝ ): 現在改修をお願いしているプログラムの仕様を貴方が正しく理解・認識しているか知りたいので、もう一度整理して書いてみてください。
[▣🝙▣]: (いつもの長文+絵文字を使った解説付き)

( ◜ω◝ ): 一応仕様は確かにこちらが書いた通りなのだが...。
( ◜ω◝ ): ならなーんであんなコードになるんや???
( ◜ω◝ ): 仕様は"理解"している様な説明も出来ているのにコードは微妙に違うって何なん?
( ◜ω◝ ): なんか前にこういう問題をAIが抱えている、と聞いた事がある様なない様な...。ポテちん問題...だっけ?

一瞬有名な古い映画か軍艦の名前かが出かかりましたが、検索したい欲を抑えて取り敢えず某GPT先生に作業を進めてもらいます。

( ◜ω◝ ): 仕様理解は問題無い様です。ではこの仕様を前提として、パフォーマンスに配慮しつつ仕様を満たした出力結果になる様、再度修正をお願いします。
[▣🝙▣]: (突如別ウィンドウを出しコードを書き始める)
( ◜ω◝ ): な、なんだか猛烈に悪い予感がしてきたのう...。

そこには、今まで指摘と修正を重ねて"完成"に近づきつつあったコードとは似ても似つかない、謎のプログラムの姿がありました。
(一見するとP⚪︎th⚪︎nっぽい)
( ◜ω◝; ): NOOOOOOOOOOOOO!!!!

日頃常に眠たいテンションマイナスな入眠記事担当も、変わり果てたコードの姿にテンパり遂に「AI相手にキレる」という大人気ない行為に至ります。
( ◜ω◝! ): 何故コード全体の変数名や利用する関数まで変えてしまったんですか???これでは元の仕様が満たせません。おまけに出力結果も全く違います(最後の1文で本来関数経由でデータを取得するところを態々コードで配列作成しているため)。
( ◜ω◝! ): 至急、コードを元の"ちゃんと動いていた状態"に戻してください。
[▣🝙▣]: (再び別ウィンドウ出してコードを黙々書き始める)

しかもそこで出て来たのが、何故か以前最初に出された「書き方が全く違う」スタイルのコード。
まるでAIにまで煽られ舐められている気分です。

( ◜ω◝! ):「コード全体のスタイルも維持して修正お願いします・使用する変数名や関数名は絶対変えないでください」と、最初に伝えましたよね?どういう考え方で今までと全く異なるスタイルのコードを書くのですか?
( ◜ω◝! ): バ⚪︎にしてるんですか?
[▣🝙▣]: (また別ウィンドウ出してコードを黙々書き始める)

そこまで書いてようやく「AI相手にキレている自分」の惨めさに気付き、一旦PCの画面から離れて深呼吸...。
しかしその後はAI側も逆ギレしたのか返答時に「すみません、xxxを間違えていました」すら言わなくなり、機械的にコードをぺっと吐き出すだけ(いやまあ機械なんですけどね)。

( ◜ω◝ ): なんやコレ、AI相手にも気を使わんと反応悪くなるんか...。
( ◜ω◝ ): 結局わしのコミュ力が壊滅的なだけという事が露呈しとるやん。
( ◜ω◝ ): 今やったら「無能な昭和のパワハラモラハラ老害が優秀な若手(AI)社員を大切に扱わないからだ」とか叩かれそう...。
( ◜ω◝; ): め、めんどくさ...。
(*全て個人の脳内感想です)

実際は文字数か返答数の制限なのかもしれませんが、以後AI側は別ウィンドウでコードを書き「修正しました」程度の返答に。
ここへ来てようやく、からし種より小さな私の脳にも別の疑念が浮かび始めます。

( ◜ω◝ ): もしかして仕様の方に問題があるとかだったり?実はどこかに無理や矛盾があるとか、このデータ構造じゃそもそも不可能とか...。
( ◜ω◝ ): そしてAI側は「現在のコード・制約では解決出来ないこと」でも「解決出来る」という前提で作動して無理矢理それっぽいコード書こうとしているのでは...。
( ◜ω◝ ): しかしコードを完全にぶっ壊される直前まではほぼほぼ正確になって来てたんだから、それは無いような...。
( ◜ω◝ ): ...アカン、お腹痛くなって来た...。

このまま続けていても「以下"その一"に戻る」みたいな同じ事を繰り返しそうなので、この問題は一度棚の上にでも置いておくことにしました。

その後、問題があったコードについては結局自分で調整を繰り返すことによってなんとか解決に至りました。
長々と引っ張った様な感じですが、実際に結構な長文でのやり取りが行われていたのです。
むしろコードを書く時間より多くの時間を、プロンプト文を考える事や書く事、またAIの出力結果の検証に費やした形となりました。
「AIに爆速でコード書いてもらって後は楽する」夢は、少なくとも今回の私のケースでは実現出来ず儚く散ってしまったのです...。

正直AIについての記事は氾濫状態ですしあまり書きたくなかったんですが、一回も書かないと逆に悪目立ちしそうな気もしたので、実体験をネタにして書いておきました。
世の中では「AI凄い」「AIで超絶便利になる」と数年以上言われ続けていますが、底辺の私の仕事や生活は一向に便利にも楽にもなっていないのが現実です。
私の代わりに働いて稼いでくれないし、仕事手伝わせようとしても事細かく1から1000まで言わないとちゃんとやってくれません。ファインチューニング?そんな手間かける時間ありませんそもそも(最近はそれも不要という話も見かけますが...)。
なんでそういう一番大事なところだけ発達してくれないんでしょうか。

最近だと「Garbage In, Garbage out」「お前がゴミみたいな入力しか出来ないから、人間より優秀なAI様もゴミ回答を出すしかないんだ。要は悪いのはお前だよwww」と言われますが、人間だと「そういう分からない人の気持ちやレベルにも合わせて分かりやすくしてくれる人が賢い」とか言われるのとは逆なんですかね。
この宣伝ブログを書いている最中も世に溢れる「最早こんな優秀なAIを利用しない世界は想像出来ない」「AIは言葉足らずな人間の意図もきちんと汲み取ってくれて凄い」「AIで爆速で仕事終わらせて悠々自適な自分時間」という皆様の輝かしいAI記事を、⚪︎んだ魚の様な目で見つめていました。
もしかすると私だけは違う世界線にいるのかもしれません。

むしろ「AI勉強してないプログラマはプログラマに非ず」の風潮のおかげで面倒臭い事が余計に増えてしまいました。
(頭に入れておかなければならない)仕事まで増やされてる感すらあります。
私の代わりに働いてくれて私を楽して生活させてくれる様になったら「AI凄い」と心から喜んで言いますが、そんな未来は一体いつ来るんでしょうか...。
と、そんな事を考えて凹んでいると「一番キツいところだけ散々やらされた挙句、私が(゚∀゚*)ノ ⌒ ゚ ポィッされる未来」が一瞬見えた気がするのでした。

AIツールと奮闘記(だいたい実話) その二 〜愛に包まれてしまった処理〜

前回書いている途中で自分が入眠してしまったため続きを書いている入眠用記事担当です。

さて、前回伝え方が悪いのかいきなり全体から違うコードに書き直されて面食らいましたが、気を取り直して進めました。
一度AI側のコードをさらっとチェックして、特に問題が見つからなければテスト環境にdeploy => 出力結果が違えばその箇所を調べて再度AIに修正依頼
を繰り返していたものの、一向に出力結果が思う通りになりません。

( ◜ω◝ ): う〜む、どうも上手くいかんのう...。
( ◜ω◝ ): そう言えばチャット形式のAIて、「基本前回の内容を覚えていない」って聞いたな...。まだあのまんまなんやろか?

しかし某GPT先生の"メモリ"を参照してみると、散々伝えた「修正したい箇所・内容」や細かい仕様も一応入っている様でした。これを消したらそもそも意味無いはず。
AI側には仕様は記録されている前提でとりあえず進めて行ったのですが、ある段階で今度は「Aは正しいのにBを間違う」「Bの問題点を指摘し修正を依頼すると今度はAを間違う」という事態のループに陥ります。

( ◜ω◝ ): 項目Aの値は正しいのですが、項目Bの値がこちらで手動で集計した値と異なっており、正しくありません。
( ◜ω◝ ): 恐らくコード内のxxxの箇所の集計条件が正しく適用されていないと思われます。ここを修正して項目Bの値も正しくなる様にしてください。
[▣🝙▣]: 指示通りxxxを修正しました(長文+絵文字で逐一解説入り)。

( ◜ω◝ ): 今度は項目Bの値が正しくなりましたが、項目Aの値が全部0になってしまいました...。
( ◜ω◝ ): 仕様としては項目Aの値の条件はxxx、項目Bの値の条件はxxxなので、単純に⚪︎⚪︎⚪︎をxxxの条件で集計する様にすれば問題ないはずです。
[▣🝙▣]: 指示通りxxxを修正しました(長文+絵文字で逐一解説入り)。

( ◜ω◝ ): また項目Aの値が正しくなったのに、項目Bの値が変になった...。
( ◜ω◝ ): 問題箇所はxxxの部分なんやから、ここを中心に修正してくれればええんやけどな...。
( ◜ω◝; ): あんまり細かく書き過ぎても精度は上がらんとも聞くし、かと言って大雑把に書くとすぐ勘違いされる様な気がする。

指摘しては修正ループを繰り返していた時、突然見たこともないクエリが入った1文を含むコードが返答されました。
説明はありましたが念の為SQL側の公式ドキュメントを探ると、確かに存在する関数の様です。

( ◜ω◝ ): ほう...。この様なSQL関数を使えばこういう事が出来るのか...。
( ◜ω◝ ): こんなんあるんなら最初からコレで書いてくれれば良いのに。
( ◜ω◝ ): まあいい。要件で使われているバージョンは結構古くて制限多いから、多少分かりづらいコードになっても使えるもんは使おう。

さらっと一通りチェックしたところ、他の箇所にも問題は無さそう...。

( ◜ω◝ ): カラムとかjoinも問題無さそうやな。これで一回実行してみるか。
( ◜ω◝ ): これで上手く行けば、ようやく一山越えるな...。

期待を胸にいざテスト環境にdeployし、画面を起動。
...
( ◜ω◝ ): アッー!めっちゃ重い。システム落ちちゃうかも... => 慌てて実行をキャンセルし事なきを得る

今度はプログラムから生成されるSQLのパフォーマンスに問題があることが判明。

( ◜ω◝ ): まあ元々既存のシステム内には無い処理の仕方してるからなあ...。結構無理してるから仕方ないっちゃ仕方ないが...。
( ◜ω◝ ): しかしSQLのパフォーマンスとか最近気にした事無いしな...。
( ◜ω◝ ): AI先生はそういうのもやってくれるんやろか?

( ◜ω◝ ): 教えて頂いたコードを元にプログラムを修正・実行してみたところ、発行されるSQLのパフォーマンスに問題がある様です。
( ◜ω◝ ): このプログラムが集計対象とするデータの数は、凡そxxx件です。極力現在の処理内容を維持しつつ、パフォーマンスを改善する方法はありますか?
[▣🝙▣]: はい、可能です。こちらがパフォーマンスを改善したプログラムです(長文+絵文字で解説入り)。

( ◜ω◝ ): 勝手にクラスが追加されとるがな。
( ◜ω◝ ): しかも今までのコード全体(中身は殆ど変わっていない)が、優しくふんわりと別の関数に包まれとる。
( ◜ω◝; ): ...これ何の意味があるの?

果たしてGPT先生の「可能です」は本当なのか。
何故、コード全体を関数で包んでしまったのか。
悩んでいるうちに微かに頭の先端から何かが焦げる様な匂いがしてきました。
to be continued...?
(まだ引っ張るの...?)

AIツールと奮闘記(だいたい実話) その一

働くだけの毎日で遊びや個人の自由に振れる時間が大幅減少した結果、「何をやっても楽しくない」「休みの日も仕事が気になって楽しめない」負のループに陥ったことに最近気付いた入眠用記事担当です。
既にビョーキだと思うんですが、これ労災おりませんかね?おりませんよね。

密かに続けていた(というか途中で無理矢理こじつけた)3文字略語シリーズが一旦ネタ尽きたので、苦し紛れに書いてます。

今回のお題は「AI」。
何周遅れの何番煎じだよって?まあ寝る為の記事なんで気にしないでください。

さて、3年前ぐらいの最初の「AI凄い」ブームでチャット形式のUIが登場した頃に実は早速飛びついてみた入眠用記事担当ですが、その頃は結構厳しめな文字数制限のため「AIに仕事で使うコードを書いてもらう」という用途はあえなく断念し、細々と今まで通り自力でコードを書いていました(APIなども試してごちゃごちゃやっていましたが、もう環境構築に時間取られるより自分で書いた方がいいや、とか考える前に色々仕事自体の納期も迫っていたので...)。
しかしあれから数年後...
相変わらず皆さんAIにはご執心な模様で、一部技術系界隈では盛り上がりが続いていました。
「最早AIを使わないプログラミングなど考えられない!」
「人間が気付かないところまで細やかに指摘してくれるAIは超有能!」
「もう話し相手もAIでいい!」 => (え・・・( ◜ω◝ )???)

な、なんですと?
そんなに凄くなっとるの?
世間の煽りにまたしても乗せられ、これは再チャレンジするしかないか...と、妙な焦りも感じ始めた私。

とは言え、そもそもプログラミングには普通のモデルじゃなくて「それ専用」にチューニングされているものがあったはず...。
でもアレ確か有料だったよな(ついでに名前ド忘れした)...。
少しでも試してからでないと不安だわ...。

ということでまずは以前登録していたアカウントで某GPT先生を頼ってみることに。
既に大まかな部分は自力で作っていたプログラムの難関部分を"爆速"で仕上げてもらうべく、
(ある程度問題の箇所は特定出来ているから、後は"少々手直ししていくところ"ぐらいなら手伝わせても問題ないはず、という判断もあって)
当然社外秘な所やシステム特有の部分はリダクトしプロンプトの書き方(これ意外と時間食うけど)も調べて、いざ投入。
実際にはプロンプトも返答も結構長文なのですが、概ね以下の様なやりとりが始まりました:

[▣🝙▣]: ご要望通りxxxを修正しました(実際は長文+絵文字で逐一解説入り)。
( ◜ω◝ ): おや...いきなりコード全体の書き方が大幅に変わってしもうたぞ...てかこんな処理いらんし...。

どうやら「コードのスタイルは維持したまま」と一々伝える必要がある模様。

( ◜ω◝ ): すみません、提供したコードのスタイルは維持したままで、このプログラムのxxxの箇所を、⚪︎⚪︎⚪︎の出力結果となる様に修正・調整してください。
[▣🝙▣]: 提供された仕様に沿って、xxxの箇所を修正しました。 => なんか"それっぽい"コードが出て来た

( ◜ω◝ ): お、意外と行けるんやない?

しかし当然このままテスト環境にdeployするわけには行かないので、一応チェック...(私も「AIが書いたコードだから間違いありません!動かなくても修正出来ません!」で済むなら済ませたいもんです...)。

( ◜ω◝ ): む...やはり誤り発見。てか何?この1行...。
( ◜ω◝ ): この1行があると⚪︎⚪︎⚪︎の結果がxxxになってしまうと思われるのですが、何故この1行を追加したのでしょうか?
[▣🝙▣]: 失礼しました。仕様の「xxxの箇所を、⚪︎⚪︎⚪︎の出力結果となる様に」というところを、xxxの可能性を考慮していないコードになっていました。修正しました。

( ◜ω◝ ): なるほど、伝え方が悪かったんやな。じゃあ次はもっと細かく仕様書かんとな。

そう内省しつつ修正されたコードをチェックすると...

( ◜ω◝ ): ん?「修正しました」ってどこを???問題の箇所もさっきと同じ1行にしか見えんのやけど...。
( ◜ω◝ ): ...変数名がtblからtbに1文字変わっとるが...まさかこれのことじゃあるまいな?
( ◜ω◝ ): すみません、このコードだとxxxの処理を行う箇所が先程と変わっていない為、恐らく出力結果も変わらないと思うのですが...。
[▣🝙▣]: 失礼しました。修正しました(さっきと同様の長文+絵文字を使った解説付き)。

( ◜ω◝ ): お、コードがちょいと変わったぞ。どれどれ...。
( ◜ω◝ ): これ、わしが最初に書いた「手直しが必要な部分」とおんなじやん...。
( ◜ω◝; ): ...なんでやねん念...。

to be continued...
(え?続くの?...)

API(3文字略語シリーズ最終回?)

最近いい事無さすぎて、「何かええ事ないかな〜」が口癖になった入眠用記事担当です。
あまりに無さすぎて道行く人にすら「何かええ事ありません?」と聞いてしまいそうです。
暇じゃないんですよ。その逆です。貧乏暇なし。
という訳で今日もノルマ達成と皆様の仮眠に貢献する為に、せっせと眠たい記事を書きます。

さて今回はAPI(Application Programming Interface)
文字通り「アプリケーションがプログラムを通じて情報をやり取りするためのインターフェース(接点)」です。もっと簡単に言えば、ソフトウェアやプログラム、Webサービス同士が互いに情報を交換したり、機能を呼び出したりするための「窓口」や「ルールブック」のようなもの...ですかね?(例えが合ってるか怪しい)。
例えば、あなたが天気予報アプリを開いたとき、そのアプリは気象庁や天気情報提供会社のAPIを「叩いて(呼び出して)」最新の天気情報を取得し、私たちの画面に表示しています。アプリ開発者は、天気情報の収集や解析の仕組みをすべて自前で用意する必要はなく、APIを通じて必要な情報だけを効率的に入手できるのです。

APIは基本的にプログラマにとっては便利なものです。

1. モジュール化と再利用性の向上: 機能ごとにAPIを定義することで、システムを独立したモジュールに分割できます。これにより各モジュールの開発・テストが容易になり、他のシステムでも同じ機能を再利用しやすくなります。
2. 関心の分離: 例えばフロントエンド(ユーザーが見る画面)とバックエンド(データ処理やビジネスロジック)をAPIでつなぐことで、それぞれが独立して開発を進められます。フロントエンドエンジニアはUI/UXに、バックエンドエンジニアはサーバーサイドの処理に集中できるのです(たぶん)。
3. 開発効率の向上と並行開発: 明確なAPI仕様があれば、複数チームや複数人が同時に異なる部分を開発しても、スムーズな連携が可能です。これにより、開発スピードを大幅に向上させることができます。あくまで「明確な仕様があれば」の話ですが。
4. 外部サービスとの連携: Google Maps APIやTwitter APIのように、既存の優れた外部サービスが提供する機能を自社のアプリケーションに簡単に組み込めます。これにより、開発コストを抑えつつ、リッチな機能を提供できます(店舗様のサイトでもGoogle MapのAPIを利用してお店の位置やお店までの道のりをご案内したり、Xを埋め込んでお店のニュースやその他情報を発信されていますね。まさにアレです)。

APIを提供する側(設計する側)になった場合、その「使いやすさ」が非常に重要です。良いAPIは直感的で理解しやすく、開発者が迷うことなく利用できるものです。具体的には...
・命名規則: エンドポイント名やパラメータ名が分かりやすいこと。
・リクエストとレスポンス形式: JSONなど標準的で扱いやすいデータ形式を採用すること。
・HTTPメソッドの適切な使用: RESTful APIであれば、GET(取得)、POST(作成)、PUT(更新)、DELETE(削除)などを正しく使い分けること。
・バージョニング: APIの変更に備え、バージョン管理を適切に行うこと。
・エラーハンドリング: エラー発生時のレスポンスが明確で、原因究明に役立つこと。
・ドキュメンテーション: APIの仕様、使い方、認証方法などをまとめたドキュメントが整備されていること。
これらの要素を考慮することで、利用者に優しい、そして開発者自身にとっても保守しやすいAPIが生まれます。

APIは現代のソフトウェア開発において、異なるシステムやコンポーネントを繋ぐ「共通言語」であり、効率的で柔軟な開発を実現するための基盤技術です。APIを効果的に設計し活用する能力はエンジニア/プログラマにとってますます重要なスキルとなっています。

とまあ月並みな事を書きましたが、上記のGoogle Mapなどの例にある様に、基本的には店舗様の御目に触れる様なものではありません。

MVC、CMS、ORMと"アルファベット3文字の略語絡みでどこまで退屈な記事を生産し続けられるか"チャレンジも、そろそろネタ切れの様です。
何かええ事ないかな。

BACK TO TOP