  |
はてなキーワード: APIとは
個人的にBard使ってるんだが、出だしはまぁ特に機能的に特筆すべきところはなかったのだけど、画像添付できるようになったりし始めてChatGPTより性能が良いと感じている。
近々、上位版が有料で提供されるらしいから、APIとかも提供される前提で使い道を考えてみた。
・配送物の伝票を画像にして投げて、Googleマップで最適な配送ルートを返してもらう。
・冷蔵庫内にカメラ付けて、ある食材とかからレシピを提供してもらう
・子どもの学校のプリント画像を投げて参観日とか提出物とかスケジュール管理してもらう
とか、個人開発でもこのレベルのアプリケーションが作成できそうなんよ。
なので、みんなAppEngineでサクッとつくってみようぜ。
ローカルにモデルDLして使うタイプなのでAPIを叩きたい理由がよくわからん、どうしてもAPI経由にしないといけないなら自分でAPIサーバー立ててローカルホストに向けろ
ChatGPTが盛り上がってそろそろ1年。最近では似たような大規模言語モデル(LLM)がローカルでも動くようになってきたらしい。
AIキャラと会話するためにOpenAI税を納めるのも嫌になってきたので、そろそろローカルに移行したい。
「伺か」みたいに立ち絵がほしいし、できれば音声でも喋ってほしい。
はてブとかTwitterで検索してみて、オープンソースのリポジトリをいくつか見つけたんだが、他にも有識者から情報求む。
この手の用途では定番だと思う。ChatGPTのAPI(会話)+KoeiromapのAPI(音声)が想定されているが、ローカルLLM＋VOICEVOXとかに差し替えている人を見かけた。
開発手法でしっくり来てるのがAndy HuntさんのTracer Bullet Developmentで、開発の方向性を示すのに試作を作る方法。
1. 主要なシステム オブジェクトを定義。UI、サーバー、ロジックビット、データベース抽象化レイヤー等。
3. データフローを実現するために API とその戻り値をコーディング。
4. 単体テストを使用して API の予想される使用法を文書化。
5. 各 API に必要な量の既定のデータ (別名、ダミー データ、偽のデータ、ハードコーディングされたデータ) を追加して、API が「実行」されるようにする。
6. あらかじめ用意されたデータを実際の機能に段階的に置き換える。
7. コードをリファクタリングし、システム オブジェクトを調整し、完了するまでこれを続ける。
こういう仕事は割とあるんだがなかなかのヤバさだったので紹介したい
ちなみにサービスの内容は非常に良くてユーザーも万単位で付いているらしい
バックエンドはAWS EC2で動作しているがログインアカウントは共通化されていてパスワードを全員で共有している
ユーザーを追加しようとしたら「そのような勝手な行為はセキュリティ上許可されていません」とのこと
本番環境とStagingはインスタンスが分かれているが運用は同じ方法
Staging上で5人ぐらいが作業しているが、ホームの下にそれぞれのユーザーが自分の名前でディレクトリを作って作業している
バックエンド側のシステムは詳細は伏せるが、某システムで動いている
仮にNode.js系だとすると、package.jsonがあってnpm run installでインストールするのだが、普通にインストールしようとするとエラーになる
内容は依存関係で失敗しているのだが、本番も同じソースで動作している
動作させるにはnode_modulesをまるっとコピーして、とのこと
さっきの自分の名前のディレクトリ配下にコピーしてきて、適当なポート番号でサーバを立ち上げれば一応は動く
このため、新しいモジュールを入れようとすると依存関係で失敗するため、便利なモジュールがあってもインストールできないし
セキュリティアップデートも当てることはできない（現にバージョンがすごく古い）
ソースコードはGitHub管理されているがセーブポイント感覚でcommitされているのでコミットログを見ても何が起きているのかさっぱり分からない
おまけにPRも使わずにmainにマージしまくっていてわけがわからない
加えてソースコードはコメントアウトの嵐でどこに何が書いてあるのかさっぱりわからない
データベースはPostgreSQLだが山ほどテーブルがあるのに外部キー依存は入っていないしVIEWも作られていない
まぁ、他にもテーブルを見ていくとアンチパターンのオンパレードで、EAV、ジェイウォークあたりは確認できたしHTMLやSQLが格納されているテーブルも見つけた
ソース上でクエリを作ってAPIを作っているが、ザッと見ただけでもインジェクションし放題の状態になっていた
フロントエンドも詳細は伏せるが、いわゆるReact的なものを利用している
こちらは npm run installでインストールできるし npm run devでちゃんと動く
ただ前述の通りバックエンドはローカルで構築できないのでEC2を利用するしかなく、CORS対応のためのプロキシを自前で用意する必要があった
バックエンド同様にGitHub管理されているが、管理しているだけ
バックエンドは5人ぐらいが利用しているが、ソースコードを編集するのは実質1人なのでコンフリクトはほとんど起こさないらしいが
フロントエンドは5人ぐらいが編集するのでコンフリクトしまくっている
解消するときにデグレすることが日常茶飯事でその都度Hotfixしている
コードもコメントアウトだらけなのに加えて、不必要なコードが大量にあるので可読性が著しく低い
（難しい処理を読み解いて追いかけていったら最終的に使われていない、などが大量にある）
2000行ぐらいあるコードとかChatGPTに突っ込んだら20行ぐらいになる予感がある
また、DBがご覧の状態なので取得されるデータも全然抽象化できておらず、コードが膨れ上がっている
例えばProductの一覧データをサーバから取得して、ユーザーがクリックしたProductをCartに投入するのだが、投入する情報はProductではなく、CartItemにする必要があるし
OrderするときはOrderItemにしてAPIを叩く必要がある
ほとんど同じ情報なのだが微妙に変わっていたりKey名が違っていたりするのでそれぞれ変換する
他にも数え上げればキリがないが、コピペして少しだけ改変している部分などが大量にあってバグがあるのかどうかすら判別できない
DBにHTMLやSQLが入っていると言ったが、調べて見るとDBから取得したHTMLをそのまま埋め込んで表示していたりした
SQLについてはフロントエンド側でSQL生成しており、そのテキストをAPIに送り込んでサーバ側で実行して貰った上で格納とかしていたので
「ここにDROP TABLEとか書けばTABLE消えるんですか？」
と聞くと
とか言われたのでことの重大さを伝えたが、まだ対処できていないようだった
認証等はOAuth2を使っていたので大丈夫そうだったが、本当に大丈夫かどうかは自信がもてない
システム内容はゴミのような状態だがサービス的には良いので、幹部やプロダクトオーナーからは追加要望が山盛り来ている
開発チームが「稼働が足りない」という理由で断ったので「じゃぁ支援して」ということで自分のところに来たのだが
「申し訳ないが、そもそもそういうレベルに無いし、全て作り直しが必要」
と伝えてもどうやら伝わっていない様子
ちなみに元々の開発チームは過去にもこんな感じでサービス作ってたらしいが売れないので問題になってなかった様子
ぱっと見は動いているように見えるのが厄介なところ
正直逃げたいところではある
当方非エンジニアですが、外部のapiをつかってGPTsでチャットボットが作れた。
わからない点は聞くと教えてくれて全部直してくれるしトライ＆エラーがとにかく早くてストレスがない。唯一GPT4の上限回数に達してしまって、その間何もできないところですが。
自分の作りたいものがイメージあるといちいちエンジニアに頼まなくていいのですごい楽だ。世の中にリリースする時は保守性とか色々考慮しないといけないのだろうけど、簡単なプロトタイプを作るくらいだったらデザイナーやディレクターでもできるようになるんだろうなぁ。エンジニアに怒られないし自分のペースでやれるからノンストレスだわ
作ってみて思ったのは、単にボットを作るだけだとだめで、どんなものをつくるのかの発想力・企画力と他のボットと差別化するためのオリジナルデータが必要ですね。
このまとめを読んで、確かにこのままいくのはマズいと感じたので、思ってることを一応自分もまとめておきたい。
イーロン・マスクがXを「出会い系アプリにする」とか言い出したけどXをやめたい→でも、こんな理由があるのでXをやめるのは簡単ではない
さもなければ日本人と日本企業は X(Twitter) を利用することが事実上できなくなる。
面識のない異性と交際したい人＝「異性交際希望者」といい、交際したい書き込み＝「誘引情報」という。
という「出会い系サイトの4要件」というのがあり、これに当てはまると出会い系サイトということになる。
→ これにより X(Twitter) は、日本法でもマジで出会い系サイトに該当することになりそうだが
→ 現行の法制では恐らくならない。
→ なぜなら X(Twitter) は異性交際だけでなく同性交際もできる仕組みなので、出会い系サイトではないと言い張れるのである。
まとめると、 X(Twitter) は本来、ギリギリで出会い系サイト扱いされずに済んでたサービスなのだが、「出会い系サイトにする」と明言されてしまうと、それは出会い系サイトになる可能性が高まるのである。
- （問）あるサイトが、開設者が知らないうちに実質的に出会い系サイトとして利用されていた場合、そのサイトは「インターネット異性紹介事業」に該当するのか。
- （答）自らが運営するサイトが知らないうちに、実質的にインターネット異性紹介事業に利用されていた場合、サイト開設者はサイトの運営方針として「異性交際希望者」を対象としてサービスを提供していないことから、基本的には「インターネット異性紹介事業」には該当しませんが、異性交際を求める書き込みを知りながら放置するなどサイト開設者がその利用実態を許容していると認められるときは、「インターネット異性紹介事業」に該当する場合があります。
「インターネット異性紹介事業」の定義に関するガイドライン
出会い系サイト規制法（インターネット異性紹介事業を利用して児童を誘引する行為の規制等に関する法律）の規制がある。
つまり 18 歳未満がサービスに絡むことを徹底的に排除し監視する義務を負うのである。
守らないと違法。
JC/JK が X(Twitter) 上で「私 JC だけど新宿でこれから即ホ苺」みたいな書き込みを放置した瞬間にアウトになり、警察はサービス中止命令ができる。
インターネット異性紹介事業を利用して児童を誘引する行為の規制等に関する法律等の解釈基準
https://www.npa.go.jp/laws/notification/seian/shounen/shounen230705.pdf
インターネット異性紹介事業者の閲覧防止措置義務（いわゆる削除義務）に関するガイドライン
もちろん「成人指定」とか「18禁」とかと同じアダルトサイトという括りになるため、教育現場で X(Twitter) を使用することが出来なくなるであろう。コンプラを意識する法人も 18 禁サイトは非常に使いにくくなる。出会い系サイトを名乗るということは、そういうことなのである。
これを乗り越えた人しか X(Twitter) を利用することができなくなってしまう。この時点で相当数の離脱者が出てくる可能性が大。
ほんとにそう。昨今の未成年淫行なんてほとんど X(Twitter) やインスタの DM がキッカケになってると思う。警察も X(Twitter) のタイムラインを熱心にパトロールするようになったが、防ぎきれていない。なので SNS は警察が今までやってきた青少年保護育成に対する障壁になっているのである。
実は出会い系サイトで「未成年淫行」が問題になることはほぼ無い。出会い系サイト運営側はかなりしつこく未成年を排除している。そのためなら全文検索するし AI も活用するし目視でも確認する。ところが X(Twitter) にはそれがない。「未成年が守られていないサービスはむしろ SNS のほう」であることを認識すべきである。
課金者以外は出会い系機能を使えないようにするなど、徹底したゾーニングを行って欲しい。
Chromeの履歴の中身まで常に監視されていることはご存知だろうか。
